RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE

[H.J. Lu]

On Mon, Sep 16, 2013 at 8:23 AM, Maciej W. Rozycki
<macro@codesourcery.com> wrote:
> On Tue, 20 Aug 2013, Michael Matz wrote:
>
>> > >> We need to increase x86-64 PLT entry size to 32 bytes to
>> > >> support Intel MPX.
>> > >
>> > > I don't like this at all.  The suggestion from Ian or Alan (don't
>> > > remember) with multiple plts sounds much better.  Only 2 plt slots per
>> > > icache line seems quite horrible when not needed.  IIRC you said "it
>> > > sounds complicated" to that idea.  I say, "so what?".  Life is hard.
>> > >
>> >
>> > The main issue is the new shared libraries/executables must work with
>> > the existing dynamic linker.
>>
>> Explain what issue you see.  In the two-plt model the existing dynamic
>> linker won't know about the second .plt, hence use the old non-bnd aware
>> slots.  I.e. they will work, but bound checking will be ineffective.  I
>> think requiring a new dynamic linker to make bounds checking work over
>> PLT borders is sensible.
>
>  FWIW the MIPS port now implements mixing PLT slot sizes within the PLT
> and no changes to ld.so were required to support this; ld.so does not
> really care about how PLT entries look like -- all it cares about are GOT
> offsets that are used to find the relevant GOT entry to relocate, and that
> x86 PLT entry code pushes onto the stack.  These offsets have no relation
> to how PLT entries have been structured within the PLT, you just need to
> push them onto stack somehow.
>
>  MIPS PLT can now include multiple entries, of a different size each,
> referring to the same GOT offset and the PLT entries are not sorted
> (anymore) in the increasing GOT offset order (the difference is the MIPS
> port passes the GOT offset in a register rather than on the stack, but
> that's a minor implementation detail that does not affect the overall
> design).  Perhaps you could take a similar approach to solve your problem.
>

I see

bfd_vma
_bfd_mips_elf_plt_sym_val (bfd_vma i, const asection *plt,
                           const arelent *rel ATTRIBUTE_UNUSED)
{
  return (plt->vma
          + 4 * ARRAY_SIZE (mips_o32_exec_plt0_entry)
          + i * 4 * ARRAY_SIZE (mips_exec_plt_entry));
}

How does it work with variable PLT entry sizes?

-- 
H.J.