This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, "Girkar, Milind" <milind dot girkar at intel dot com>, "Kreitzer, David L" <david dot l dot kreitzer at intel dot com>
- Date: Mon, 19 Aug 2013 10:31:05 -0700
- Subject: Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- References: <CAMe9rOp=1v38F_aV-pbv50YOGSEr_ju+byZP1L_G_h4bm5Ad3w at mail dot gmail dot com> <20130814154948 dot GR1814 at tucnak dot redhat dot com>
On Wed, Aug 14, 2013 at 8:49 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Jul 23, 2013 at 12:49:06PM -0700, H.J. Lu wrote:
>> There are 2 psABI considerations:
>>
>> 1. Should PLT entries in all binaries, with and without MPX, be changed
>> to 32-byte or just the necessary ones?
>
> Ugh, please don't.
>
>> 2. Only branch to PLT entry with BND prefix needs 32-byte PLT entry. If
>> we use 32-byte PLT entry only when needed, it can be decided by:
>> a. A new MPX PLT relocation:
>> i. No new run-time relocation since MPX PLT relocation is
>> resolved to branch to PLT entry at link-time.
>> ii. Pro: No new section.
>> iii. Con:
>> Need a new relocation.
>> Can't mark executable nor shared library.
>
> I think I prefer new relocation, @mpxplt or similar. The linker could then
> use the 32-byte PLT slot for both @plt and @mpxplt relocs if there is at
> least one @mpxplt reloc for the symbol, otherwise it would use 16-byte PLT
> slot. And you can certainly mark executables or PIEs or shared libraries
> this way, the linker could do that if it creates any 32-byte PLT slot.
We don't have to add @mpxplt since we have "bnd" prefix. We also
need to handle "bnd call foo" in executable. We can add new BND
version relocation for R_X86_64_PC32 and R_X86_64_PLT32, instead
of using the GNU attribute section. Which approach is preferred?
--
H.J.