What is R_X86_64_GOTPLT64 used for?

  On Thu, Nov 13, 2014 at 9:03 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>

Linker does:

        case R_X86_64_GOT64:
        case R_X86_64_GOTPLT64:
           base_got = htab->elf.sgot;

          if (htab->elf.sgot == NULL)
            abort ();

          if (h != NULL)
            {
              bfd_boolean dyn;

              off = h->got.offset;
              if (h->needs_plt
                  && h->plt.offset != (bfd_vma)-1
                  && off == (bfd_vma)-1)
                {
                  /* We can't use h->got.offset here to save
                     state, or even just remember the offset, as
                     finish_dynamic_symbol would use that as offset into
                     .got.  */
                  bfd_vma plt_index = h->plt.offset / plt_entry_size - 1;
                  off = (plt_index + 3) * GOT_ENTRY_SIZE;
                  base_got = htab->elf.sgotplt;
                }

So if  a symbol is accessed by both @GOT and @PLTOFF, its
needs_plt will be true and its got.plt entry will be used for
both @GOT and @GOTPLT.  @GOTPLT has no advantage
over @GOT, but potentially wastes a PLT entry.

Here is a patch to mark relocation 30 (R_X86_64_GOTPLT64)
as reserved.  I pushed updated x86-64 psABI changes to

https://github.com/hjl-tools/x86-64-psABI/tree/hjl/master

I will update linker to keep accepting relocation 30 and
treat it the same as R_X86_64_GOT64.

What is R_X86_64_GOTPLT64 used for?

Commit Message

Comments

Patch