This is the mail archive of the
mailing list for the GCC project.
Re: What is R_X86_64_GOTPLT64 used for?
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: "x86-64-abi at googlegroups dot com" <x86-64-abi at googlegroups dot com>, GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 20 Nov 2014 07:04:46 -0800
- Subject: Re: What is R_X86_64_GOTPLT64 used for?
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOqb0g2asAe6UZ0hxh8jFf-+eBiaez0pLrPjd0oqVdP0Rg at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1411131717220 dot 405 at wotan dot suse dot de> <CAMe9rOrTg=YtVZ1EqN7ha8qUPSXzms20eMU51txVAmL3+cUsQQ at mail dot gmail dot com> <CAMe9rOrnQRo3XXowAEcd_h=i_i5v04=i=kLWjm2ANduv8MwhYQ at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1411171425020 dot 405 at wotan dot suse dot de> <CAMe9rOppfTEwtRROsAhFf+7tFjv7pRZ8qho-3NOC7BxvfSBaKg at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1411201416070 dot 405 at wotan dot suse dot de>
On Thu, Nov 20, 2014 at 5:42 AM, Michael Matz <email@example.com> wrote:
> Exactly. As a symbol lookup needs to be done anyway for the GLOB_DAT
> reloc going through the dynamic linker for the lazy lookup later when a
> call occurs doesn't make sense.
>> jmp *name@GOTPCREL(%rip)
>> 8 byte nop
> You mean replacing the PLT slot with the above? Yep, something like that.
> Even better of course would be to not use the PLT slot at all, it's just a
> useless indirection. It would be even cooler to rewrite the call insn
> call foo@PLT
> call *foo@GOTPCREL(%rip)
> (in the small model here) Unfortunately the latter is one byte larger
> than the former. But perhaps GCC could already emit the latter form
> when it knows a certain function symbol has its address taken (or more
> precisely if a GLOB_DAT reloc is going to be emitted for it).
>> where name@GOTPCREL points to the normal GOT slot
>> updated by R_X86_64_GLOB_DAT relocation at run-time.
>> Should I give it a try?
> Frankly, I have no idea if it's worth it. Address takings of function
> symbols doesn't occur very often, except in vtables, and that's not using
> GOT slots. Vtables should be handled in a completely different way
> anyway: as the entries aren't usually used for address comparisons they
> should point to the PLT slots, so that it's only RELATIVE relocs, not
> symbol based ones, so that also virtual calls can be resolved lazily.
I fixed a bug on hjl/plt.got branch:
It passed glibc tests and bootstrapped GCC. It optimized functions like