This is the mail archive of the
mailing list for the GCC project.
Re: What is R_X86_64_GOTPLT64 used for?
- From: Michael Matz <matz at suse dot de>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- 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, 13 Nov 2014 17:33:18 +0100 (CET)
- 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>
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
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
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.
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