Considering the following test-case: $ cat 0.s .cfi_startproc bl .LTHUNK32.lto_priv.0 .cfi_endproc $ cat 1.s _ZN8CryptoPP5Weak19ARC4_Base11ProcessDataEPhPKhm: .globl .LTHUNK32.lto_priv.0 .hidden .LTHUNK32.lto_priv.0 .set .LTHUNK32.lto_priv.0,_ZN8CryptoPP5Weak19ARC4_Base11ProcessDataEPhPKhm .cfi_startproc .cfi_endproc $ gcc [01].s -shared -fPIC -o libx.so -fuse-ld=bfd && nm libx.so | grep THUNK 0000000000000738 t .LTHUNK32.lto_priv.0 U LTHUNK32.lto_priv.0 $ echo 'int main() {}' | gcc -x c - -lx -L. /usr/lib64/gcc/powerpc64-suse-linux/11/../../../../powerpc64-suse-linux/bin/ld: ./libx.so: undefined reference to `LTHUNK32.lto_priv.0' collect2: error: ld returned 1 exit status while ld.gold does not created the undefined symbol: $ gcc [01].s -shared -fPIC -o libx.so -fuse-ld=gold && nm libx.so | grep THUNK 0000000000000758 t .LTHUNK32.lto_priv.0
$ ld --version GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4
Note that it does not happen on ppc64le: $ gcc [01].s -shared -fPIC -o libx.so && nm libx.so | grep THUNK 0000000000000764 t .LTHUNK32.lto_priv.0 $ ld.bfd --version GNU ld version 2.27-44.base.el7 tested on gcc112.fsffrance.org
Started with 8c5b4e5228ec94923fbdfb0008926b0b2a3f51c2: PowerPC64 dot-symbol compatibility bugfixes Lots of fixes for the compatibility code that handles linking of -mcall-aixdesc code (or that generated by 12 year old gcc) with current ELFv1 ABI code. ...
With the original powerpc64 ELF ABI, which for functions defined both a symbol on a descriptor and a "dot-symbol" on the code entry point, "bl .LTHUNK32.lto_priv.0" looks like a call to a function "LTHUNK32.lto_priv.0". There doesn't seem to be a descriptor for LTHUNK32.lto_priv.0, which there should be for this ABI. That said, the linker does try to deal with all sorts of horrible code, and in this testcase the only thing going wrong is leaving a dynamic symbol reference to the (linker supplied) function descriptor symbol. I'll see what I can do about removing that unused dynamic symbol. Gold doesn't error here because it refuses to deal with the old ABI dot-symbols on calls.
Thank you Alan for taking care of it. Yes, the unresolved symbol is a problem for linking against such a library.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a442059f66075e4e503c43b119cc8b7de04e5718 commit a442059f66075e4e503c43b119cc8b7de04e5718 Author: Alan Modra <amodra@gmail.com> Date: Tue Nov 2 19:01:06 2021 +1030 PR28523, ld.bfd created undefined symbols on ppc64 This patch removes any fake (linker created) function descriptor symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic symbols are not created. The change to func_desc_adjust requires that it be run only once, which means ppc64_elf_tls_setup can't call it for just a few selected symbols. PR 28523 * elf64-ppc.c (func_desc_adjust): If a function entry sym is not dynamic and has no plt entry, hide any associated fake function descriptor symbol. (ppc64_elf_edit): Move func_desc_adjust iteration over syms to.. (ppc64_elf_tls_setup): ..here.
The binutils-2_37-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b1d7b59622f9941e7fa72418b7a41f148d83155e commit b1d7b59622f9941e7fa72418b7a41f148d83155e Author: Alan Modra <amodra@gmail.com> Date: Tue Nov 2 19:01:06 2021 +1030 PR28523, ld.bfd created undefined symbols on ppc64 This patch removes any fake (linker created) function descriptor symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic symbols are not created. The change to func_desc_adjust requires that it be run only once, which means ppc64_elf_tls_setup can't call it for just a few selected symbols. PR 28523 * elf64-ppc.c (func_desc_adjust): If a function entry sym is not dynamic and has no plt entry, hide any associated fake function descriptor symbol. (ppc64_elf_edit): Move func_desc_adjust iteration over syms to.. (ppc64_elf_tls_setup): ..here. (cherry picked from commit a442059f66075e4e503c43b119cc8b7de04e5718)
Fixed on 2.37 and mainline.
Great, thank you very much!