commit 0a0cd78b3f82092cda116f96e47111053dff18d2
author Philip Reames <preames@rivosinc.com> Wed Jan 17 14:32:20 2024 -0800
committer Copybara-Service <copybara-worker@google.com> Wed Jan 17 14:36:32 2024 -0800
tree 880166f79c1197c29d7ccd7527b3959d59da805f
parent de220633568a29ad0386cea07e3e03503f307541

[LLD][RISCV] Report error for unsatisfiable RISCV_ALIGN (#74121)

If we have a RISCV_ALIGN relocation which can't be satisfied with the
available space provided, report an error rather than silently
continuing with a corrupt state.

For context, https://github.com/llvm/llvm-project/pull/73977 fixes an
LLD bug which can cause this effect, but that's not the only source of
such cases.

Another is our hard-to-fix set of LTO problems. We can have a single
function which was compiled without C in an otherwise entirely C module.
Until we have all of the mapping symbols and related mechanisms
implemented, this case can continue to arise.

I think it's very important from a user interface perspective to have
non-assertion builds report an error in this case. If we don't report an
error here, we can crash the linker (due to the fatal error at the
bottom of the function), or if we're less lucky silently produce a
malformed binary.

There's a couple of known defects with this patch.

First, there's no test case. I don't know how to write a stable test
case for this that doesn't involve hex editing an object file, or
abusing the LTO bug that we hope to fix.

Second, this will report an error on each relax iteration. I explored
trying to report an error only once after relaxation, but ended up
deciding I didn't have the context to implement it safely.

I would be thrilled if someone more knowledgeable of this code wants to
write a better version of this patch, but in the meantime, I believe we
should land this to address the user experience problem described above.

GitOrigin-RevId: 987123e4f1a6e1713b7c684e696e9b1cd8d595ea