[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