[PATCH] D158003: [lld-macho] Stricter Bitcode Symbol Resolution
Kyungwoo Lee via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 22 08:22:02 PDT 2023
kyulee marked an inline comment as done.
kyulee added inline comments.
================
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
----------------
thevinster wrote:
> 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.
This is the case where we error out where we can't resolve the prevailing symbol correctly.
I think blocking `module asm` itself is an overkill given there exists user code that already has assembly.
I think this is a peculiar case where `module asm` is used to hold a reference that is even not defined in this compilation unit.
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