Hi all, 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. Thanks, Ilya 2013/8/19 H.J. Lu <hjl.to...@gmail.com>: > On Wed, Aug 14, 2013 at 8:49 AM, Jakub Jelinek <ja...@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.