Bug 27203 - ld ppc: Emit R_PPC64_IRELATIVE instead of R_PPC64_JMP_SLOT for non-preemptible ifunc referenced by a DSO
Summary: ld ppc: Emit R_PPC64_IRELATIVE instead of R_PPC64_JMP_SLOT for non-preemptibl...
Status: RESOLVED NOTABUG
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.37 (HEAD)
: P2 normal
Target Milestone: ---
Assignee: Alan Modra
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-18 21:30 UTC by Fangrui Song
Modified: 2021-01-19 23:59 UTC (History)
0 users

See Also:
Host:
Target: powerpc*
Build:
Last reconfirmed: 2021-01-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fangrui Song 2021-01-18 21:30:19 UTC
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
Comment 1 Alan Modra 2021-01-18 22:02:09 UTC
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
Comment 2 Alan Modra 2021-01-19 00:49:16 UTC
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.
Comment 3 cvs-commit@gcc.gnu.org 2021-01-19 02:59:40 UTC
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.
Comment 4 cvs-commit@gcc.gnu.org 2021-01-19 03:02:26 UTC
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)
Comment 5 H.J. Lu 2021-01-19 12:49:29 UTC
(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
Comment 6 Alan Modra 2021-01-19 23:59:48 UTC
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.