[PATCH] D108006: [lld][ELF] Add --no-search-static-libs-for-shlib-undefined flag

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 12 22:08:54 PDT 2021


MaskRay added a comment.

It's important to have symmetry.  a) `ld.lld def.a ref.so` b) `ld.lld ref.so def.a`.
The patch addresses a) but not b).

(
I have noticed missing test coverage. The following diff doesn't cause a test failure.

  --- i/lld/ELF/Symbols.cpp
  +++ w/lld/ELF/Symbols.cpp
  @@ -744,3 +744,4 @@ template <class LazyT> void Symbol::resolveLazy(const LazyT &other) {
   
  -  other.fetch();
  +  if (!isShared())
  +    other.fetch();
   }

)

---

I am trying to understand the rationale behind this symbol resolution rule.
On one side, it resembles Windows link.exe and Mach-O ld64: AFAIK they don't use undefined symbols in DLL/dylib for resolution.

On the other side, I strive to think of some scenarios where this rule is both sensible and mandatory, but cannot think of one.
The closest thing I can think of:

  echo '.globl _start; _start: call bb' > a.s
  echo '.globl bb; bb: call cc' > b.s
  echo '.globl cc; cc: nop' > c.s
  cc -c a.s b.s c.s
  rm -f c.a && ar rc c.a c.o
  ld -shared -z defs c.o -o c.so
  ld -shared -z defs b.o ./c.so -o b.so
  
  ld -rpath=. a.o b.so c.a
  # a.out defines cc. ld.lld, ld.bfd, and gold have the same behavior.

c.so and c.a are built from the same set of object files.
b.so is linked with -Bsymbolic and depends on c.so

For `ld ... b.so c.a`, if ld extracts c.a to satisfy b.so, the c.a definition may conflict (ODR violation) with c.so.
Keep c.a unextracted is probably the intention.

I'd say the bug is that c.so and c.a cannot be used together.
The user should not do both things: (1) let b.so link against c.so (2) let the executable link against c.a .
Using `--no-undefined` (`-z defs`) for shared objects is not an exuse.

If the executable really needs to use c.a, the shared objects cannot use c.so.
Currently it is difficult to make `--no-undefined` happy because we don't support an option listing all allow undefined symbols.
(If we want to add such an option, the option can be modeled after --just-symbols.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108006



More information about the llvm-commits mailing list