[PATCH] x86: Check invalid TLS descriptor call

Alexandre Oliva oliva@gnu.org
Wed Sep 4 00:53:55 GMT 2024


On Sep  2, 2024, "H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Mon, Sep 2, 2024 at 10:53 AM Alexandre Oliva <oliva@gnu.org> wrote:
>> 
>> On Aug 31, 2024, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> 
>> > On Sat, Aug 31, 2024 at 4:07 AM Alexandre Oliva <oliva@gnu.org> wrote:
>> >>
>> >> On Aug 29, 2024, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> >>
>> >> > TLS descriptor call,
>> >> > call *x@tlsdesc(%rax)
>> >>
>> >> > or
>> >>
>> >> > call *x@tlsdesc(%eax)
>> >>
>> >> > calls _dl_tlsdesc_return which expects that RAX/EAX points to the TLS
>> >> > descriptor.
>> 
>> >> But it doesn't follow that one must not use any other register that
>> >> holds a copy of %[er]ax for the call, does it?
>> 
>> > Did you mean that
>> 
>> > lea foo@tlsdesc(%ebx), %eax
>> > mov %eax, %ecx
>> > call *foo@tlscall(%ecx)
>> 
>> > also works?
>> 
>> I didn't quite mean that; I meant there's no reason why it couldn't be
>> made to work.
>> 

> Of course, many different code sequences can work.  Since RAX/EAX
> is the pointer to the TLS descriptor, why isn't it used?

Oh, it would be used, and the TP offset would land in %eax regardless of
the register used for the call or for the load.

I can't think of a reason why someone would *want* to preserve the TLS
descriptor address in another register, or load it into another register
and then copy it, but there doesn't seem to be a reason to rule that out
either (that's my point).  Here's a scenario where it might be sensible
for some imaginary x86 hardware:

  lea foo@tlsdesc(%ebx), %ecx  # set up address early
... # unrelated intervening instructions
  mov %ecx, %eax  # prepare for the call
  call *foo@tlscall(%ecx) # but use ecx to avoid a (theoretical?) pipeline stall

ISTM that the linker relaxations, as specified, would work just fine for
these arrangements as well, but I haven't checked the instruction
encodings, maybe there are surprises there.  Anyway, there doesn't seem
to be a compelling reason to embrace these variants, so we might as well
regard and report them as unsupported.

> Besides linker issues an error if RAX/EAX isn't used when there is a
> TLS transition.

That seems excessive; it could presumably be turned into a warning if
this sort of construct turns out to be useful at some point.

-- 
Alexandre Oliva, happy hacker                  https://FSFLA.org/blogs/lxo/
   Free Software Activist                         GNU Toolchain Engineer
GNU's Day, qui tollis peccata mundi, libera nobis, dona nobis IV libertates


More information about the Binutils mailing list