This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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/7 Jakub Jelinek <jakub@redhat.com>:
> 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


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