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

Thu Apr 30 02:44:29 PDT 2020

int3 marked an inline comment as done.
int3 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
+
----------------
smeenai wrote:
> 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.
Oh gotcha. And yeah, you're right, we're not handling those GOT relocations quite correctly right now...

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79114