cat > ./a.s <<eof resolver: nop .globl ifunc, _start .type ifunc, @gnu_indirect_function .set ifunc, resolver _start: bl ifunc nop eof echo 'bl ifunc; nop' > ./b.s powerpc64le-linux-gnu-as a.s -o a.o powerpc64le-linux-gnu-gcc -shared -fpic b.s -o b.so % ~/Dev/binutils-gdb/out/ppc64le/ld/ld-new a.o b.so -o a % readelf -Wr a Relocation section '.rela.plt' at offset 0x228 contains 1 entry: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000010020010 0000000100000015 R_PPC64_JMP_SLOT ifunc() ifunc + 0 ld should use R_PPC64_IRELATIVE for a non-preemptible ifunc symbol. If I remove b.so from the linker command line, R_PPC64_IRELATIVE will be used. (This just documents a case that ppc64 has not adopted https://sourceware.org/bugzilla/show_bug.cgi?id=23169) % readelf -W --dyn-syms a | grep ifunc 1: 0000000010000260 0 IFUNC GLOBAL DEFAULT 7 ifunc
And attempting to link with gold gives gold/ld-new: internal error in do_plt_fde_location, at /home/alan/src/binutils-gdb/gold/powerpc.cc:3949
I generated a patch to change powerpc64 to use R_PPC64_IRELATIVE in this situation, but now I'm wondering if such a change is a good idea. IRELATIVE relocs must be resolved at program startup whereas JMP_SLOT can be resolved lazily. So we'd be slowing down program startup for no benefit at all if the function is never called, and only saving ld.so symbol resolution time if the function is called. I'm inclined to think this isn't a good idea.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a75a6a416477915b7d236537c9170ced3064df11 commit a75a6a416477915b7d236537c9170ced3064df11 Author: Alan Modra <amodra@gmail.com> Date: Tue Jan 19 13:19:18 2021 +1030 [GOLD] powerpc assertion failure A testcase with only ifuncs can result in no plt section (ifunc plt entries might instead be in iplt), which means we can get to this code without a static link. PR 27203 * powerpc.cc (do_plt_fde_location): Remove doing_static_link assertion.
The binutils-2_36-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d235291c81996095afa31b5fa59a325f0bf7236e commit d235291c81996095afa31b5fa59a325f0bf7236e Author: Alan Modra <amodra@gmail.com> Date: Tue Jan 19 13:19:18 2021 +1030 [GOLD] powerpc assertion failure A testcase with only ifuncs can result in no plt section (ifunc plt entries might instead be in iplt), which means we can get to this code without a static link. PR 27203 * powerpc.cc (do_plt_fde_location): Remove doing_static_link assertion. (cherry picked from commit a75a6a416477915b7d236537c9170ced3064df11)
(In reply to Alan Modra from comment #2) > I generated a patch to change powerpc64 to use R_PPC64_IRELATIVE in this > situation, but now I'm wondering if such a change is a good idea. IRELATIVE > relocs must be resolved at program startup whereas JMP_SLOT can be resolved > lazily. So we'd be slowing down program startup for no benefit at all if > the function is never called, and only saving ld.so symbol resolution time > if the function is called. > > I'm inclined to think this isn't a good idea. Will it help https://sourceware.org/bugzilla/show_bug.cgi?id=23169
Gold bug fixed, and preparation for changing ld behaviour committed 30845f113a3b. I don't intend to make that change in behaviour. > Will it help > https://sourceware.org/bugzilla/show_bug.cgi?id=23169 No, using irelative makes things worse. irelative is resolved at load time so there is no possibility of lazy resolution leaving ifunc relocation until all after other relocs are applied.