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: Jan Beulich <JBeulich at suse dot com>
- Cc: Binutils <binutils at sourceware dot org>, GDB <gdb-patches at sourceware dot org>
- Date: Mon, 19 Aug 2013 10:44:28 -0700
- Subject: Re: RFC: Use .plt section sh_entsize instead of GET_PLT_ENTRY_SIZE
- References: <CAMe9rOp9JdK96fXHL-ViJxMh371kgxONgYTHeXrYnBfm4AgdjQ at mail dot gmail dot com> <5208B18F02000078000EB06C at nat28 dot tlf dot novell dot com>
On Mon, Aug 12, 2013 at 12:57 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 09.08.13 at 19:16, "H.J. Lu" <email@example.com> wrote:
>> We need to increase x86-64 PLT entry size to 32 bytes to
>> support Intel MPX. But elf_x86_64_plt_sym_val uses the
>> hardcoded PLT entry size and disassembler can't deal
>> with a different PLT entry size. For x86-64, PLT entry size
>> is the same as .plt section sh_entsize. We can use it instead.
>> This assumes .sh_entsize is set correctly. Both ld and gold
>> handle it properly. Will this change cause any problems?
> Wasn't your plan to support a mixture of 16- and 32-byte
> entries? In which case considering the entry size to be 16
> would remain to be correct?
Is mixed 16/32 byte PLT entry option on the table?
Will it work with the existing dynamic linker?