[llvm-dev] Demotion of shared symbols resolved from the dynamic linker. (original) (raw)

Fāng-ruì Sòng via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 28 12:43:48 PST 2020

On Fri, Feb 28, 2020 at 7:24 AM Sean Fertile via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On PowerPC we have a failing address sanitizer test when linking with LLD. _The issue is that the symbol 'libcstackend' is resolved to an undefined weak symbol when linking with LLD but not when linking (with the exact same command/input) with other linkers. Tracing the symbol I see it is resolved to a definition in the dynamic linker as expected:

/home/sfertile/LLVMMonoRepo/build/lib/clang/11.0.0/lib/linux/libclangrt.asan-powerpc64le.a(sanitizerlinux.cpp.o): _reference to libcstackend _/lib/powerpc64le-linux-gnu/libpthread.so.0: reference to libcstackend _/lib/powerpc64le-linux-gnu/ld64.so.2: shared definition of libcstackend _: reference to libcstackend The last line in the trace output shows where we demote the shared definition to an undefined symbol here: https://github.com/llvm/llvm-project/blob/c8bfed05e21f945b5ac71cd01d62e2854a8ddcf9/lld/ELF/Driver.cpp#L1505 I'm guessing the fix is that if needsInterpSection() is true then the dynamic linker should be marked as needed. Its going to end up in the DTNEEDED anyway so the symbols can't become dangling references. In my case then, the demotion won't happen and everything works as expected. Is this the right direction?

Can you name the target and upload a reproduce file (--reproduce=) ?

I have checked the x86-64 case: clang -fsanitize=address -fuse-ld=lld a.c -o a -Wl,-y,__libc_stack_end The demotion works as expected. ld.so is linked because of AS_NEEDED(...) in libc.so (a linker script). It is dropped from DT_NEEDED entries because it only provides definitions resolving weak references.

--dynamic-linker= pointing to ld.so does not mean ld.so will be added to DT_NEEDED. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200228/fdfb9b94/attachment.html>

More information about the llvm-dev mailing list