This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Michael Matz <matz at suse dot de>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GDB <gdb-patches at sourceware dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 16 Sep 2013 16:23:12 +0100
- Subject: Re: RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOp9JdK96fXHL-ViJxMh371kgxONgYTHeXrYnBfm4AgdjQ at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1308121516060 dot 6497 at wotan dot suse dot de> <CAMe9rOrprNR+n-WpWo0nMXkW+FNWQSN2wVGumu1-FEht1iFsUA at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1308200911190 dot 6497 at wotan dot suse dot de>
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.
HTH,
Maciej