This is an archive of the discontinued LLVM Phabricator instance.

[ELF2] Implement --start-group,--end-group
Needs RevisionPublic

Authored by shankare on Oct 23 2015, 5:25 PM.

Details

Summary

This implements start-group and end-group functionality. Majority of applications on linux need this functionality.

Diff Detail

Event Timeline

shankare updated this revision to Diff 38284.Oct 23 2015, 5:25 PM
shankare retitled this revision from to [ELF2] Implement --start-group,--end-group.
shankare updated this object.
shankare added a project: lld.
shankare added a subscriber: llvm-commits.
emaste added a subscriber: emaste.Oct 23 2015, 5:27 PM
ruiu edited edge metadata.Oct 23 2015, 5:36 PM

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.

Bigcheese edited edge metadata.Oct 23 2015, 6:28 PM

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.

ruiu added a subscriber: ruiu.Oct 23 2015, 7:24 PM

What's the point of that?

grimar added inline comments.Oct 24 2015, 2:12 AM
test/elf2/Inputs/startendgroup/a.s
5

Filenames of inputs are very uninformative. Usually the same name as test name are used, eg:
shared.s
Inputs\shared.s
Inputs\shared2.s

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.

grimar requested changes to this revision.Oct 24 2015, 2:13 AM
grimar edited edge metadata.
This revision now requires changes to proceed.Oct 24 2015, 2:13 AM

I am trying to say without --start-group and --end-group, the linker would have produced an unresolved symbol.

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.

ruiu added a comment.Oct 26 2015, 1:22 PM

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.

rafael edited edge metadata.Oct 27 2015, 5:21 AM
rafael added a subscriber: rafael.

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.

ikudrin resigned from this revision.Oct 30 2015, 12:58 AM
ikudrin removed a reviewer: ikudrin.
emaste removed a subscriber: emaste.Oct 30 2015, 4:53 AM
davide removed a reviewer: davide.Oct 30 2015, 12:42 PM
grimar removed a reviewer: grimar.Nov 13 2015, 8:42 AM
espindola requested changes to this revision.Mar 14 2018, 5:02 PM
espindola added a subscriber: espindola.

This is not relevant anymore.