This is the mail archive of the 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

2013/10/1 Jakub Jelinek <>:
> 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?


>         Jakub

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