Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
2013/10/2 Ilya Enkovich : > 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. Seems assembler may not always detect MPX relocation. For simple calls it may check for 'bnd' prefix, but for indirect call we need to generate MPX relocation for 'mov' instruction storing address of the called function. This instruction does not have any prefix and therefore compiler has to specify relocation by itself. Ilya > > 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
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
On Mon, Oct 07, 2013 at 01:31:29PM +0400, Ilya Enkovich wrote:
> Seems assembler may not always detect MPX relocation. For simple calls
> it may check for 'bnd' prefix, but for indirect call we need to
> generate MPX relocation for 'mov' instruction storing address of the
> called function. This instruction does not have any prefix and
> therefore compiler has to specify relocation by itself.
Ugh, not only mov I guess.
You can easily have:
int *fn1 (int *, int *);
int *fn2 (int *, int *);
typedef int (*fnt) (int *, int *);
fnt fns[2] = { fn1, fn2 };
So perhaps we need some directive that will say that all the relocations
that could be used to refer to PLT slots need to be turned into
corresponding MPX relocations? Or assembler switch.
Jakub
Re: Update the c++1y/c++14 support page
On 10/06/2013 03:19 PM, Morwenn Ed wrote: Ok, no problem then, here is the patch. And the changelog. I hope they are ok, I have never properly submitted anything before. Patch looks great to me, thanks. I'm applying it. Thanks, Paolo.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
2013/10/7 Jakub Jelinek :
> On Mon, Oct 07, 2013 at 01:31:29PM +0400, Ilya Enkovich wrote:
>> Seems assembler may not always detect MPX relocation. For simple calls
>> it may check for 'bnd' prefix, but for indirect call we need to
>> generate MPX relocation for 'mov' instruction storing address of the
>> called function. This instruction does not have any prefix and
>> therefore compiler has to specify relocation by itself.
>
> Ugh, not only mov I guess.
> You can easily have:
>
> int *fn1 (int *, int *);
> int *fn2 (int *, int *);
> typedef int (*fnt) (int *, int *);
> fnt fns[2] = { fn1, fn2 };
>
> So perhaps we need some directive that will say that all the relocations
> that could be used to refer to PLT slots need to be turned into
> corresponding MPX relocations? Or assembler switch.
Compiler can always make a decision knowing whether MPX code is
generated in current module or not. I think in this and all other
similar cases compiler should use something like @mpx or @mpxplt and
assembler would generate proper relocation then. For your example it
would look like:
fns:
.quad fn1@mpx
.quad fn2@mpx
And if we introduce new relocation in compiler then we also may use
them for mpx calls/jumps. Support in assembler would be quite simple
then, without a necessity to make a decision when to use MPX
relocation.
Ilya
>
> Jakub
Re: Update the c++1y/c++14 support page
> This has nothing to do with Oracle v. Google, but with GCC policy of not > requiring a copyright assignment for small patches from the first-time > contributors (which Paolo knows as a long-time GCC hacker). I think it's a valid reminder that that policy needs to be interpreted carefully and that there may well be some small patches that *do* need an assignment.
