This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Support re-exports of individual symbols
ClosedPublic

Authored by int3 on Feb 15 2023, 5:42 PM.

Details

Reviewers
smeenai
Group Reviewers
Restricted Project
Commits
rG4f086218ddc3: [lld-macho] Support re-exports of individual symbols
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 Timeline

int3 created this revision.Feb 15 2023, 5:42 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 15 2023, 5:42 PM
int3 requested review of this revision.Feb 15 2023, 5:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 15 2023, 5:42 PM
smeenai accepted this revision.Mar 25 2023, 9:30 PM
smeenai added a subscriber: smeenai.

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.

lld/MachO/SyntheticSections.cpp
982–983

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.

This revision is now accepted and ready to land.Mar 25 2023, 9:30 PM

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.

int3 added a comment.Mar 27 2023, 12:53 PM

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...

lld/MachO/SyntheticSections.cpp
982–983

ooh, that's definitely cleaner. Thanks!

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...

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.

int3 updated this revision to Diff 508783.Mar 27 2023, 1:36 PM

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
This revision was automatically updated to reflect the committed changes.