Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for "object libraries" -- a "--start-lib"/"--end-lib" like mode in lld-macho #52931

Closed
oontvoo opened this issue Dec 30, 2021 · 5 comments
Closed

Support for "object libraries" -- a "--start-lib"/"--end-lib" like mode in lld-macho #52931

oontvoo opened this issue Dec 30, 2021 · 5 comments
Assignees
@MaskRay
Labels
lld:MachO lld

Comments

@oontvoo
Copy link
Member

oontvoo commented Dec 30, 2021 •
edited
Loading

This allows it to accept "-objlib foo.o", which lazily includes foo.o into the link, as if it was in an archive file.

Edit: (Optional)
Also support spelling of "//-objlib". This allows it to be passed through older versions of Clang properly, when spelled as "-Wl,//-objlist". Older Clang versions will invoke the linker with "-filelist", which can only pass "filenames", not options, so we pretend to be a filename.
@smeenai
Copy link
Collaborator

smeenai commented Jan 6, 2022

Does ld64 have equivalent functionality, or would it be an extension? It's fine either way; I was just wondering where the -objlib spelling came from :)

@oontvoo
Copy link
Member Author

oontvoo commented Jan 6, 2022

I don't think it does. This is one of our internal LD64 optimisations, which I'd like preserve.
We kind of made up the name. :)

@MaskRay
Copy link
Member

MaskRay commented Jan 6, 2022 •
edited
Loading

I prefer start/end because it conveys more information and matches ld.lld/lld-link.

In ld.lld, --start-lib a.o b.o --end-lib means a.o and b.o conceptually belong to the same archive (which implies -( -)) and helps this feature: https://maskray.me/blog/2021-06-13-dependency-related-linker-options#warn-backrefs
(As my article says, I understand that ld64 never has the GNU ld/gold semantics.)

For -objlib a.o -objlib b.o, it is unclear whether a.o and b.o should belong to the same archive.

Note that this feature should be carefully implemented so that it is possible to use this lazy object file to model ArchiveFile as well for eager initialization of symbol table/section https://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster#parallel-initialization-of-sections

Actually I have some interest to implement this, as I did some work for ELF and PE/COFF, even just to find a random contribution I can make :)

@oontvoo
Copy link
Member Author

oontvoo commented Jan 6, 2022

Re: start/end
I'd prefer not to go that route because LD64 doesn't have any stateful flag like that (i know GOLD, for eg., does).
But if you all think it's ok then 👍

Feel free to take it! 👏 thanks!

@MaskRay MaskRay self-assigned this Jan 10, 2022
@MaskRay MaskRay mentioned this issue Jan 10, 2022
Open
@MaskRay
Copy link
Member

MaskRay commented Jan 10, 2022

Patch: https://reviews.llvm.org/D116913

mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
@MaskRay
[lld-macho] Add --start-lib --end-lib
3e9a093 
In ld.lld, when an ObjFile/BitcodeFile is read in --start-lib state, the file is
given archive semantics. --end-lib closes the previous --start-lib. A build
system can use this feature as an alternative to archives. This patch ports
the feature to lld-macho.

--start-lib and --end-lib are positional, unlike usual ld64 options.
I think the slight drawback does not matter as (a) reusing option names
make build systems convenient (b) `--start-lib a.o b.o --end-lib` conveys more
information than an alternative design: `-objlib a.o -objlib b.o` because
--start-lib makes it clear which objects are in the same conceptual archive.
This provides flexibility (c) `-objlib`/`-filelist` interaction may be weird.

Close llvm/llvm-project#52931

Reviewed By: #lld-macho, Jez Ng, oontvoo

Differential Revision: https://reviews.llvm.org/D116913
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MaskRay MaskRay

Labels
lld:MachO lld
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@MaskRay @smeenai @oontvoo