Re: What is R_X86_64_GOTPLT64 used for?

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Nov 13, 2014 at 8:33 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 13 Nov 2014, H.J. Lu wrote:
>
>> x86-64 psABI has
>>
>> name@GOT: specifies the offset to the GOT entry for the symbol name
>> from the base of the GOT.
>>
>> name@GOTPLT: specifies the offset to the GOT entry for the symbol name
>> from the base of the GOT, implying that there is a corresponding PLT entry.
>>
>> But GCC never generates name@GOTPLT and assembler fails to assemble
>> it:
>
> I've added the implementation for the large model, but only dimly remember
> how it got added to the ABI in the first place.  The additional effect of
> using that reloc was supposed to be that the GOT slot was to be placed
> into .got.plt, and this might hint at the reasoning for this reloc:
>
> If you take the address of a function and call it, you need both a GOT
> slot and a PLT entry (where the existence of GOT slot is implied by the

That is correct.

> PLT of course).  Now, if you use the normal @GOT64 reloc for the
> address-taking operation that would create a slot in .got.  For the call
> instruction you'd use @PLT (or variants thereof, like PLTOFF), which
> creates the PLT slot _and_ a slot in .got.plt.  So, now we've ended up
> with two GOT slots for the same symbol, where one should be enough (the
> address taking operation can just as well use the slot in .got.plt).  So
> if the compiler would emit @GOTPLT64 instead of @GOT64 for all address
> references to symbols where it knows that it's a function it could save
> one GOT slot.

@GOTPLT will create a PLT entry, but it doesn't mean PLT entry will
be used.  Only @PLTOFF will use PLT entry.  Linker should be smart
enough to use only one GOT slot, regardless if @GOTPLT or @GOT
is used to take function address and call via PLT.  However, if
@GOTPLT is used without @PLT, a PLT entry will be created and unused.

I'd like to propose

1. Update psABI to remove R_X86_64_GOTPLT64.
2. Fix assembler to take @GOTPLT for backward compatibility,
3. Make sure that linker uses one GOT slot for @GOT and @PLTOFF.

> So, I think it was supposed to be a small optimization hint.  But it never
> was used in the compiler ...
>
>> [hjl@gnu-6 pr17598]$ cat x.S
>> movabs $foo@GOTPLT,%rax
>> [hjl@gnu-6 pr17598]$ gcc -c x.S
>> x.S: Assembler messages:
>> x.S:1: Error: relocated field and relocation type differ in signedness
>
> ... and now seems to have bit-rotted.
>
>> [hjl@gnu-6 pr17598]$
>>
>> It certainly isn't needed on data symbols.  I couldn't find any possible
>> usage for this relocation on function symbols.
>
> The longer I think about it the more I'm sure it's the above optional
> optimization mean.
>

The reason I am asking about it is I'd like to finish
the large model support in binutils and GCC. I have
filed a couple bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63842
https://sourceware.org/bugzilla/show_bug.cgi?id=17592
https://sourceware.org/bugzilla/show_bug.cgi?id=17593

I will fix all of them and verify that large model works correctly.


-- 
H.J.