This is an archive of the discontinued LLVM Phabricator instance.

[LLD][RISCV][NFC] Allow GNU linker to run RISCV LLD tests
AbandonedPublic

Authored by gkm on May 2 2022, 12:11 PM.

Details

Summary

Allow RISC-V LLD tests to run on GNU ld. This is useful for checking divergences in behavior.

Diff Detail

Event Timeline

gkm created this revision.May 2 2022, 12:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 2 2022, 12:11 PM
gkm requested review of this revision.May 2 2022, 12:11 PM
gkm edited the summary of this revision. (Show Details)May 2 2022, 12:12 PM

Why can't people just symlink GNU ld to ld.lld?

gkm updated this revision to Diff 426482.May 2 2022, 12:14 PM

Fix stale comment

gkm added a comment.May 2 2022, 12:16 PM

Why can't people just symlink GNU ld to ld.lld?

Since GNU ld has separate binaries for 32-bit and 64-bit, it's not a 1-for-1 replacement.

gkm updated this revision to Diff 426484.May 2 2022, 12:18 PM

Add commented-out 32-bit GNU linker alongside 64-bit

MaskRay requested changes to this revision.EditedMay 2 2022, 12:19 PM

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!)

This revision now requires changes to proceed.May 2 2022, 12:19 PM

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.

gkm added a comment.May 2 2022, 12:29 PM

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.

gkm added a comment.May 2 2022, 12:33 PM

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.

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.

gkm abandoned this revision.May 3 2022, 1:21 PM

RIP