https://sourceware.org/bugzilla/show_bug.cgi?id=24342

            Bug ID: 24342
           Summary: [gold] Avoid plt generation for function pointer when
                    building with -fno-plt
           Product: binutils
           Version: 2.32
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: romain.geissler at amadeus dot com
                CC: ian at airs dot com
  Target Milestone: ---

Hi,

I have a case locally where ld.bfd and ld.gold don't perform the same kind of
relocation wrt PLT generation when initially building with -fno-plt.

Please see this remark in this gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954#c7 which I copy/paste here:

<<END_OF_QUOTE
n...@gcc.gnu.org 2019-01-23 16:23:24 UTC
note that with

void f_noplt(void) __attribute__((noplt));
void (*p)(void) = f_noplt;

the linker may create a PLT for f_noplt and use its address to initialize p in
case of non-pie linking.

alternatively the linker may emit a dynamic relocation for p so it is filled in
by the dynamic linker to the actual address of f_noplt.

it seems the bfd linker on x86_64 does the latter (if there is otherwise no
PLT),
but e.g. the gold linker does the former. (as far as the sysv abi is concerned
both behaviours are correct, the linker does not know about the noplt attr.)

this means that (depending on linker behaviour) a noplt function may get a PLT
in
non-pie executables (so noplt can only avoid lazy binding and jump slot relocs
reliably in pic code), may be linkers should be fixed so noplt always avoids
PLT
(on x86_64, other targets have other issues with non-pic), but then this has to
be abi to be reliable.
END_OF_QUOTE

And indeed in my case linking with bfd avoid the PLT, while linking with gold
doesn't. In my case the symbol is "malloc" which is called quite often, so I
would have hoped to avoid the PLT to avoid the trampoline overhead at each
call.

Would it be possible to update gold to better match the behavior of ld.bfd ? By
the way, apparently it's also the behavior of ld.lld.

Cheers,
Romain

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Reply via email to