Allow RISC-V LLD tests to run on GNU ld. This is useful for checking divergences in behavior.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Since GNU ld has separate binaries for 32-bit and 64-bit, it's not a 1-for-1 replacement.
I agree that people should just symlink ld.lld to ld.bfd to check this, or hack their local lit.local.cfg.
Such changes do not need to be in the upstream.
Note: many lld/test/ELF tests are very sensitive to addresses. I have improved many tests to be more or less address agnostic but many still do.
Sometimes addresses or offsets are hard-coded because otherwise it's difficult to detect errors like offset-by-N.
(I know that ld64, GNU ld, gold, and mold testsuite tend to check very little on the addresses and offsets => that makes them error-prone to such bugs.)
(BTW: Thanks for taking a look at RISC-V linker relaxation!)
What happens when we want to use LLD-specific options or are checking LLD-specific messages? Those tests aren't going to pass. Do we then need to annotate LLD tests with REQUIRES: lld-is-actually-lld? Is there any precedent for doing this on other architectures? This doesn't feel right to me.
This is a developer aid for periodically checking divergences in behavior, it is not for production or routine use.
Failed tests are tolerable, and might merit a comment on a case-by-case basis.
There is precedent for testing against other linkers, e.g., MachO LLD vs. LD64.
That would be easy if a single GNU ld were a drop-in replacement for ld.lld, but GNU ld is split into 32-bit and 64-bit configs.
I suppose a wrapper script that inspects ELF type of objects can suffice. For that matter, a wrapper script could find the right instance of GNU ld for any arch and ABI.
OK, you talked me into that approach.