This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]