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: Ilya Enkovich <enkovich dot gnu at gmail 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: Tue, 1 Oct 2013 14:27:40 +0200
- 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>
- Reply-to: Jakub Jelinek <jakub at redhat dot 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.