This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Michael Matz <matz at suse dot de>, GDB <gdb-patches at sourceware dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 16 Sep 2013 11:39:26 -0700
- 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> <alpine dot DEB dot 1 dot 10 dot 1309140227010 dot 29360 at tp dot orcam dot me dot uk>
On Mon, Sep 16, 2013 at 8:23 AM, Maciej W. Rozycki
> 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.
_bfd_mips_elf_plt_sym_val (bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
+ 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?