[PATCH] D93369: [lld-macho] Add support for weak references

Jez Ng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 16 07:36:42 PST 2020


int3 marked an inline comment as done.
int3 added inline comments.


================
Comment at: lld/MachO/SymbolTable.cpp:75
+  else if (auto *dynsym = dyn_cast<DylibSymbol>(s))
+    dynsym->weakRef |= isWeakRef;
+  else if (auto *undefined = dyn_cast<Undefined>(s))
----------------
thakis wrote:
> Is that how it works? One weak ref makes all refs weak? I would've expected that one non-weak ref makes the whole symbol non-weak, but I haven't checked. Semantically it kind of makes sense: If your program has a single non-weak call to a symbol, there can't be a need for the symbol to be weak. Maybe that's what explains the ld64 behavior for functions?
> I would've expected that one non-weak ref makes the whole symbol non-weak

I expected this too, but ld64 doesn't do this for non-function symbols. I can't see a good reason for the inconsistency between functions and non-functions, so I guess we have to make a choice. Making weakness take priority has the advantage of being more permissive -- if ld64 succeeds in linking a given binary, so should we. But there's a good argument for not implementing dubious behavior until we have a concrete use case.

tl;dr I'll switch to having non-weak take priority


================
Comment at: lld/test/MachO/symtab.s:61
 # CHECK-NEXT:   Symbol {
 # CHECK-NEXT:     Name: dyld_stub_binder (15)
+# CHECK-NEXT:     Extern
----------------
thakis wrote:
> (a bit weird that llvm-readobj output doesn't include weakness)
it does -- these particular symbols are just not weak references. I modified this test case because we're now marking all dylib symbols as `extern`, which I believe is the right behavior. And that was done because `nm` doesn't interpret the weakref flag correctly if `extern` isn't set.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93369



More information about the llvm-commits mailing list