As an optimization for ld64 sometimes it can be useful to not export any
symbols for top level binaries that don't need any exports, to do this
you can pass -exported_symbols_list /dev/null, or new with Xcode 14
(ld64 816) there is a -no_exported_symbols flag for the same behavior.
This reproduces this behavior where previously an empty exported symbols
list file would have been ignored.
Details
- Reviewers
int3 oontvoo - Group Reviewers
Restricted Project - Commits
- rG272bf0fc41e6: [lld-macho] Add support for exporting no symbols
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/MachO/Driver.cpp | ||
---|---|---|
1412–1413 | tangential & existing code, but this seems kind of redundant to me lol. We're already erroring out, doesn't seem like there's a need to tell the user we're ignoring unexports. (Not sure there's a need to clear the unexported symbols list either, but I suppose it might make any subsequent error messages less confusing.) | |
1416 | hmm should we make it an error to use -no_exported_symbols with -exported_symbol as well? | |
1561 | IMO this check is a bit confusing because it conflates a perf optimization with an actual difference in behavior. How about having the Config be something like struct Config { ... bool explicitExports = false; SymbolPatterns exportPatterns; // (can represent both `exportedSymbols` and `unexportedSymbols`) }; With exportPatterns interpreted differently based on the value of explicitExports. Then this if check becomes if (config->explicitExports) { ... That said I know this is existing code, and refactoring it can be rightly said to be out of scope :) |
lld/MachO/Driver.cpp | ||
---|---|---|
1413 | (very nit: I find this name a bit hard to read, since empty is also a verb and this reads like "should I empty the exported symbols list" to me) |
lld/MachO/Driver.cpp | ||
---|---|---|
1561 | agreed - perhaps get rid of the two unexportedSymbols and exportedSymbols lists and have just one list then a flag to say what the list means? |
lld/MachO/Driver.cpp | ||
---|---|---|
1412–1413 | Removed this, it was silently ignored anyways because of the order of the if statement below. If we find a case where error messages are degraded without it I guess we should add it back with a test showing that case. | |
1561 | So I did the first suggestion here with the explicit exports, I'm not sure if it would be as clear if we joined exportedSymbols and unexportedSymbols but if folks generally prefer that I can change it! |
tangential & existing code, but this seems kind of redundant to me lol. We're already erroring out, doesn't seem like there's a need to tell the user we're ignoring unexports. (Not sure there's a need to clear the unexported symbols list either, but I suppose it might make any subsequent error messages less confusing.)