[llvm-bugs] [Bug 43618] Possible mis-link of a binary when lld used as linker

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43618

Fangrui Song <i at maskray.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #32 from Fangrui Song <i at maskray.me> ---
Works as intended.

In an as-needed case, libpthread.so is not in the DT_NEEDED list because there
is no non-weak relocation referencing it (__pthread_key_create references from
libstdc++.so.6 are weak)

Quote http://www.sco.com/developers/gabi/latest/ch4.symtab.html

> The behavior of weak symbols in areas not specified by this document is implementation defined. Weak symbols are intended primarily for use in system software. Applications using weak symbols are unreliable since changes in the runtime environment might cause the execution to fail.

In practice, a relocation referencing an undefined weak may or may not have a
dynamic relocation.

Arch Linux extra/clang enables -fPIE by default. The code sequence is like:

  cmpq   $0x0,__pthread_key_create at gotpcrel(%rip)

The linker will allocate a GOT entry and produce a dynamic relocation. At
runtime, if libpthread.so is loaded, the value is filled in.

With -no-pie LTO, llvm codegen (called by lld) will generate:

  movl $__pthread_key_create, %eax

The linker will resolve this at link time. At runtime, even if libpthread.so is
loaded, the value will not change.


The suggestion is already in my comment #20. Don't use unterminated
-Wl,--as-needed for -lpthread

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200321/51e6bbc7/attachment.html>