This implements start-group and end-group functionality. Majority of applications on linux need this functionality.
Details
Diff Detail
Event Timeline
This is not how we handle archive files in the new LLD. --start-group and --end-group are already supported. You may need to read COFF/README.md, which is referenced by ELF/README.md, first to get the idea of the new linker's architecture.
Specifically we do not implement the exact same semantics that ld does for performance reasons. If we ever find a compelling reason to implement those semantics we would add it as a separate mode. So far we have not seen a reason to do so.
Thanks Ruiu, Bigcheese. It would become confusing for the user when migrating from the GNU linker.
I am trying to say without --start-group and --end-group, the linker would have produced an unresolved symbol.
test/elf2/Inputs/startendgroup/a.s | ||
---|---|---|
5 | Filenames of inputs are very uninformative. Usually the same name as test name are used, eg: | |
test/elf2/startendgroup.s | ||
19 | As Rui already said, --start-group and --end-group are already supported. Your test will PASS and without your code. Thats because lld currently already works in the way when it does not need --start-group and --end-group in command line to resolve it. These options are silently ignored, see Options.td. |
And if you wanted to simulate ld behavior to produce unresolved symbols when inputs not in start/end group then your test does seem to check that case.
How are symbols resolved when there are multiple --start-group and --end-group options currently ? Which symbol is picked when there is a unresolved symbol from the second group ?
If we want to follow --start-group/--end-group with the lld ELF linker, I think its best to follow GNU completely.
You have to take a look at the actual code of the new linker and understand
its semantics/performance/simplicity before you claim that the best way is
something else.
If we want to follow --start-group/--end-group with the lld ELF linker, I
think its best to follow GNU completely.
I am late to this thread, but I wanted to point out that "follow GNU
completely" is not how we want to implement *anything* in lld.
We want to start with the simpler/faster solution and make it more gnu like
only the first one is found to be insufficient for an existing real world
project and it would be cumbersome for them to change.
Cheers,
Rafael
I am late to this thread, but I wanted to point out that "follow GNU
completely" is not how we want to implement *anything* in lld.
Thank you. I believe there's a vanishingly small set of projects that rely on behaviour unique to GNU ld, can't be trivially updated to accommodate LLD, and can't just link with GNU ld instead, via -fuse-ld=bfd.
Our experience with Clang in FreeBSD is broadly illustrative - Clang is our /usr/bin/cc and the vast majority of the ~25K third-party ports build and work just fine despite minor differences compared with GCC. A few hundred do not, and have an explicit dependency on GCC. The same thing can easily be done when we bring in LLD as /usr/bin/ld.
Filenames of inputs are very uninformative. Usually the same name as test name are used, eg:
shared.s
Inputs\shared.s
Inputs\shared2.s