RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE

Maciej W. Rozycki macro@codesourcery.com
Mon Sep 16 15:23:00 GMT 2013

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.



More information about the Binutils mailing list