PR/55600
Details
- Reviewers
thevinster - Group Reviewers
Restricted Project - Commits
- rGfae6bd7563ca: [lld-macho] Support -non_global_symbols_strip_list…
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/MachO/Config.h | ||
---|---|---|
97 | This is for local symbols so the name can be more specific. One idea is enum class LocalSymbolPolicy { All, None, IncludeSelected, ExcludeSelected, }; | |
lld/MachO/Driver.cpp | ||
1443 | FWIW ld.lld uses error: ... and ... may not be used together | |
lld/MachO/SyntheticSections.cpp | ||
709 | Drop formatting | |
966 | It seems simpler to use bool(Symbol *) and let the for loop call addSymbol(localSymbols, sym); |
lld/MachO/Driver.cpp | ||
---|---|---|
1421 | nit: variable name seems clearer if it's named includeLocal/excludeLocal. | |
lld/MachO/SyntheticSections.cpp | ||
971 | Does this case need to be enumerated if it's already being filtered out below? | |
lld/test/MachO/local-symbol-output.s | ||
74 | Can we also have a test for interactions with -unexported_symbol as well? Specifically, that a global doesn't get included in the symbol table? |
rename variables per suggestion
lld/MachO/SyntheticSections.cpp | ||
---|---|---|
971 |
Yes, because we don't need to do the check on line 1009 and line 1019. We only do that check on line 991+ is because iterating through all the inputfiles and their symbols is expensive - hence if we can avoid it (ie. when -x is set), then we should | |
lld/test/MachO/local-symbol-output.s | ||
74 | I'm not sure I understand the test you're proposing. Can you give an example? |
lld/MachO/Driver.cpp | ||
---|---|---|
1416–1417 | Just to check here, does ld64 also do the same here? Wondering if this specific to our implementation or inheriting behavior for ld64. I do agree it's confusing and maybe we should disallow it if no one actually does this in practice. | |
lld/MachO/SyntheticSections.cpp | ||
971 | Whoops missed that part. Thanks for clarifying | |
lld/test/MachO/local-symbol-output.s | ||
74 | Right, -x and -non_global_symbols_[no_]strip_list don't matter to global symbols but unexported symbols can make them non-global. For example, .globl _foo .globl _bar _foo: ret _bar: ret What I'm thinking is if _foo in the test case above is unexported with -x, I would to expect to see only _bar in the symbol table since -x would've stripped away _foo. We can also apply this to -non_global_symbols_strip_list and non_global_symbols_no_strip_list well by checking that the unexported symbol should've been stripped and not stripped from the symbol table, respectively. |
lld/MachO/Driver.cpp | ||
---|---|---|
1416–1417 | Yes, that's from LD64. People may not do it on purpose but perhaps generated link commands do this. I'd slightly prefer we error-ing out for simplicity but given the behaviour is not too complex to imitate, I don't feel strongly about it, hence the TODO note. Does anyone else have a strong opinion on this? Otherwise, happy to just delete the TODO and be done with this edge case :) | |
lld/test/MachO/local-symbol-output.s | ||
74 | added tests |
Sorry for the belated review. Took me a little longer than expected to get back in the swing of things :)
lld/MachO/Driver.cpp | ||
---|---|---|
941 | I would prefer to avoid naming things "helper" if there is a more descriptive name available. E.g. something like parseSymbolPatternsFile seems like a good fit here | |
956 | nit: insert line break before functions for easy vim { } movement :p | |
1418–1419 | did you have a build that used both together? IMO we should prefer implementation simplicity by default in cases where ld64's behavior is questionable | |
1429 | extra newline | |
lld/MachO/SyntheticSections.cpp | ||
971 | seems worthwhile to explain this in a comment (see below) | |
990–1000 | could state explicitly that localSymbolsHandler will do the right thing regardless, but that this is a perf optimization | |
1018–1019 | I think we lack a test case for this private extern code path |
addressed in https://reviews.llvm.org/D126792
lld/MachO/Driver.cpp | ||
---|---|---|
1418–1419 | Yeah - can we keep this for now? (I'll find out from the builds' owner whether the usage was intentional or if it could be cleaned up). |
This is for local symbols so the name can be more specific. One idea is