Specifically, we support this:
ld64.lld -dylib foo.o libbar.dylib -exported_symbol _bar -o libfoo.dylib
Where _bar is defined in libbar.dylib.
Paths
| Differential D144153
[lld-macho] Support re-exports of individual symbols ClosedPublic Authored by int3 on Feb 15 2023, 5:42 PM.
Details
Summary Specifically, we support this: ld64.lld -dylib foo.o libbar.dylib -exported_symbol _bar -o libfoo.dylib Where _bar is defined in libbar.dylib.
Diff Detail
Event TimelineHerald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 15 2023, 5:42 PM Comment Actions It's interesting that ld64 overloads -exported_symbol for this purpose instead of having an explicit -reexported_symbol analog to -reexported_symbols_list. We should follow suit though, of course. I'll leave the comment about handleExplicitExports to your judgment. LGTM otherwise.
This revision is now accepted and ready to land.Mar 25 2023, 9:30 PM Comment Actions Looks like ld64 actually has the same behavior for -exported_symbols_list as well (so they're consistent on that front). I believe we'll do the same already, but it's probably worth adding a test to be explicit. Comment Actions I don't really think a test for that is super necessary, the -exported_symbols_list is simply command-line sugar over -exported_symbol, and I don't think every variation of how -exported_symbol gets used needs to have a corresponding _list test...
Comment Actions
Fair enough. My logic was that I personally found it surprising that -exported_symbols_list performs re-exporting even though there's also -reexported_symbols_list and thought it might be useful to be explicit about that in a test. On the other hand, like you said, since -exported_symbols_list is equivalent to -exported_symbol, it does make sense that they'd behave identically in this aspect too (and would be really weird if it didn't). Not an issue either way. Comment Actions move logic to handleExplicitExports; also add test to show -unexported_symbol has no effect on dylibs This revision was landed with ongoing or failed builds.Mar 27 2023, 1:39 PM Closed by commit rG4f086218ddc3: [lld-macho] Support re-exports of individual symbols (authored by int3). · Explain Why This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 508784 lld/MachO/Driver.cpp
lld/MachO/ExportTrie.cpp
lld/MachO/Symbols.h
lld/MachO/SyntheticSections.cpp
lld/test/MachO/export-options.s
|
What do you think of moving this logic to handleExplicitExports in Driver.cpp and setting a flag on the DylibSymbol that's checked here instead? I ask because that one is parallelized, which presumably means that provided a measurable speedup in some builds, plus it seems conceptually nicer to handle the checking in one place.