[PATCH] D79114: [lld-macho] Dylib symbols should always replace undefined symbols

Shoaib Meenai via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 30 00:34:58 PDT 2020


smeenai added inline comments.


================
Comment at: lld/test/MachO/resolution.s:27-28
+## But defined symbols should take precedence.
+# OBJ-FIRST-NOT: libresolution _bar
+# OBJ-FIRST-NOT: libresolution _baz
+
----------------
int3 wrote:
> smeenai wrote:
> > Where are `_bar` and `_baz` defined in this assembly file?
> ah, I was under the impression that I didn't need to define them because they were already appearing in the symtab, but I realize they were appearing as undefined symbols instead of the global/local defined symbols that I wanted. Will fix, thanks
> 
> > I believe we should already be implementing this behavior, courtesy of a Defined replacing any other symbol, but it's worth adding a test.
> 
> Yeah this is what _bar and _baz are supposed to test :)
For the particular case I was thinking of, you'd need to have the dylib appear in the link line before the object file, to confirm that a Defined symbol replaces a DylibSymbol.

Also, it's not too relevant for this particular test, but it's an interesting question of what it means to have a `GOTPCREL` relocation against a symbol in your own binary (especially a symbol that's not even external, like `_baz` here). ld64 creates GOT entries for those symbols. I believe we won't right now, since our GOT creation is based on whether the relocation is targeting a dylib symbol vs. what the type of the relocation is.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79114/new/

https://reviews.llvm.org/D79114





More information about the llvm-commits mailing list