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, 13 Nov 2014 09:03:49 -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>
On Thu, Nov 13, 2014 at 8:33 AM, Michael Matz <email@example.com> wrote:
> 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
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:
I will fix all of them and verify that large model works correctly.