LLD resolves symbols before performing LTO compilation, assuming that the symbols in question are resolved by the resulting object files from LTO. However, there is a scenario where the prevailing symbols might be resolved incorrectly due to specific assembly symbols not appearing in the symbol table of the bitcode. This patch deals with such a scenario by generating an error instead of silently allowing a mis-linkage.
If a prevailing symbol is resolved through post-loaded archives via LC linker options, a warning will now be issued.
Details
- Reviewers
int3 thevinster ellis - Group Reviewers
Restricted Project - Commits
- rGa033184abb80: [lld-macho] Stricter Bitcode Symbol Resolution
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Overall, lgtm. Minor comments
lld/MachO/SymbolTable.cpp | ||
---|---|---|
155 | Can we also add a condition to cast this file as a bitcode file just make sure that it is in fact a bitcode file? | |
156–166 | So if I understand the comment here correctly, A has a module asm symbol that is defined in B, but incorrectly resolves it to the bitcode file instead of the object file? This dependency issue kinda seems like a bug rather than a limitation and I wonder if this scenario should be supported. Though using module asm in source is already sketchy, in itself, so it might be worth error-ing to as a forcing function to make users fix their errors at the right level. |
lld/MachO/SymbolTable.cpp | ||
---|---|---|
156–166 | This is the case where we error out where we can't resolve the prevailing symbol correctly. |
Can we also add a condition to cast this file as a bitcode file just make sure that it is in fact a bitcode file?