Re: [PATCH v2] x86-64: Update _dl_tlsdesc_dynamic to preserve vector registers

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Feb 12, 2024 at 2:44 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > Compiler generates the following instruction sequence for GNU2 dynamic
> > TLS access:
> >
> >       leaq    tls_var@TLSDESC(%rip), %rax
> >       call    *tls_var@TLSCALL(%rax)
> >
> > CALL instruction may be transparent to compiler which assumes all
> > registers, except for RAX, are unchanged after CALL.  At run-time,
> > _dl_tlsdesc_dynamic is called, which calls __tls_get_addr on the
> > slow path.  __tls_get_addr is a normal function which doesn't
> > preserve any caller-saved registers.  _dl_tlsdesc_dynamic saves and
> > restores integer caller-saved registers, but doesn't preserve any
> > vector registers which are caller-saved.  Add _dl_tlsdesc_dynamic
> > IFUNC functions for FXSAVE, XSAVE and XSAVEC to save and restore
> > all vector registers.  This fixes BZ #31372.
>
> What about the flags register?  It's still clobbered.

(define_insn "*tls_dynamic_gnu2_call_64_<mode>"
  [(set (match_operand:PTR 0 "register_operand" "=a")
    (unspec:PTR [(match_operand 1 "tls_symbolic_operand")
           (match_operand:PTR 2 "register_operand" "0")
           (reg:PTR SP_REG)]
          UNSPEC_TLSDESC))
   (clobber (reg:CC FLAGS_REG))] <<<<<<< clobbered
  "TARGET_64BIT && TARGET_GNU2_TLS"
  "call\t{*%a1@TLSCALL(%2)|[QWORD PTR [%2+%a1@TLSCALL]]}"
  [(set_attr "type" "call")
   (set_attr "length" "2")
   (set_attr "length_address" "0")])

> What about stack pointer alignment?

Fixed by

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

My glibc patch assumes that the stack is aligned to 8 bytes.
But it only affects the FXSAVE IFUNC.  XSAVE IFUNC requires
64-byte alignment anyway.

> > +     /* Besides rdi and rsi, saved above, save rcx, rdx, r8, r9,
> > +        r10 and r11.  */
>
> I would prefer to see some explicit ABI action first before making such

It is explicitly documented:

https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt

---
The functions defined above use custom calling conventions that
require them to preserve any registers they modify.  This penalizes
the case that requires dynamic TLS, since it must preserve (*) all
call-clobbered registers before calling __tls_get_addr(), but it is
optimized for the most common case of static TLS, and also for the
case in which the code generated by the compiler can be relaxed by the
linker to a more efficient access model: being able to assume no
registers are clobbered by the call tends to improve register
allocation.  Also, the function that handles the dynamic TLS case will
most often be able to avoid calling __tls_get_addr(), thus potentially
avoiding the need for preserving registers.
---

Glibc simply doesn't preserve vector registers.

> I would prefer to see some explicit ABI action first before making such
> decisions.  Maybe %r11 could be a scratch register available for use by

%r11 is caller-saved, not available.

> the TLSDESC call?  Or does current GCC already assume that all scalar
> registers are preserved?

GCC assumes that only FLAGS_REG is reserved and RAX is the destination
register.  Everything else must be preserved.

> The other way to fix this is to preallocate everything, so that the need
> for the slow path goes away.

True.


-- 
H.J.