This is the mail archive of the
mailing list for the binutils project.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail 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: Wed, 14 Aug 2013 17:49:48 +0200
- 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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.