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: Michael Matz <matz at suse dot de>
- To: "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: Tue, 20 Aug 2013 09:28:12 +0200 (CEST)
- Subject: Re: RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE
- 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>
Hi,
On Mon, 19 Aug 2013, H.J. Lu 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.
Halving the number of plt slots per cache line for everyone for a feature
of questionable utility (*) OTOH doesn't seem nice.
Ciao,
Michael.
(*) Sorry, I'm really not convinced that MPX is such a marvellous feature
to warrant the plt bloat.