[PATCH] D158003: [lld-macho] Stricter Bitcode Symbol Resolution
Vincent Lee via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 21 03:42:40 PDT 2023
thevinster accepted this revision.
thevinster added a comment.
This revision is now accepted and ready to land.
Overall, lgtm. Minor comments
================
Comment at: lld/MachO/SymbolTable.cpp:155
+ auto objFile = dyn_cast<ObjFile>(file);
+ if (!objFile) {
+ // The file must be a native object file, as opposed to potentially
----------------
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?
================
Comment at: lld/MachO/SymbolTable.cpp:156-166
+ // The file must be a native object file, as opposed to potentially
+ // being another bitcode file. A situation arises when some symbols
+ // are defined thru `module asm` and thus they are not present in the
+ // bitcode's symbol table. Consider bitcode modules `A`, `B`, and `C`,
+ // LTO compiles only `A` and `C`, since there's no explicit symbol
+ // reference to `B` other than a symbol from `A` via `module asm`.
+ // After LTO is finished, the missing symbol now appears in the
----------------
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.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158003/new/
https://reviews.llvm.org/D158003
More information about the llvm-commits
mailing list