This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, 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, 2 Oct 2013 14:02:24 +0400
- Subject: Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOp=1v38F_aV-pbv50YOGSEr_ju+byZP1L_G_h4bm5Ad3w at mail dot gmail dot com> <20130814154948 dot GR1814 at tucnak dot redhat dot com> <CAMe9rOp8V+V_iBWdu=wQRs-hWmTKvhEHqy_SnGzeMB0sPP2wzQ at mail dot gmail dot com> <CAMbmDYaU=vTGKne63Ji-Em2D8tyJaRUOix1B33vN4D-kTPqqaw at mail dot gmail dot com> <20131001122740 dot GB30970 at tucnak dot zalov dot cz>
2013/10/1 Jakub Jelinek <jakub@redhat.com>:
> On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote:
>> I'd like to restart discussion on this topic. I see two viable options
>> in this thread for PLT entry for MPX.
>>
>> The first one is to use new relocation for calls requiring extended
>> PLT. Linker may decide then which PLT entries should be extended and
>> use 16 byte entries when possible. The only question here is how
>> dynamic linker may detect MPX binary and try to search for MPX shared
>> libraries. Does it have access to PLT section to check it? Isn't still
>> better to just use note section?
>>
>> The second one is a note section. It does not have as good granularity
>> as new relocation but in the most cases all calls in MPX object file
>> would require extended PLT. Therefore linker create extended PLT entry
>> if it used by function from object files marked with the MPX note
>> section. The only drawback here is that old linker will just silently
>> ignore this note section and user have to check linker version.
>>
>> Due to mentioned drawback of the second approach I would vote for the
>> new relocation but still with note section for dynamic liker.
>
> Whether the PLT is extended or not can be determined either by the kind
> of dynamic relocations applied to it (either the relocation for
> non-PLT resp. PLT MPX calls should be only for ld(1) purposes and not
> dynamic, or there could be also some dynamic relocation, counterpart of
> R_*_JMP_SLOT). In the former case, if the dynamic linker would need to find
> out if the PLT is extended or not for some reason, the linker could add some
> .dynamic tag, that is the usual way to handle this kind of stuff.
I do not see the reason for new dynamic relocation now. Adding PLT MPX
calls for ld is enough. As H.J. suggested it wouldn't require any
changes in compiler, 'as' may just check for 'bnd' prefix in
instruction and generate proper relocation for ld.
Having an entry in .dynamic section with special MPX tag is a good
idea. No need for a new section then.
Does anyone see flaws in this scheme?
Thanks,
Ilya
>
> Jakub