[PATCH] LoongArch: Add support for TLS Descriptors

Florian Weimer fweimer@redhat.com
Mon Dec 4 08:49:04 GMT 2023


* Xi Ruoyao:

> On Mon, 2023-12-04 at 09:13 +0100, Florian Weimer wrote:
>> * Xi Ruoyao:
>> 
>> > I made up this:
>> > 
>> > diff --git a/sysdeps/loongarch/Makefile b/sysdeps/loongarch/Makefile
>> > index 43d2f583cd..64c1ea1294 100644
>> > --- a/sysdeps/loongarch/Makefile
>> > +++ b/sysdeps/loongarch/Makefile
>> > @@ -15,3 +15,16 @@ ASFLAGS-.os += $(pic-ccflag)
>> >   ifeq (yes,$(have-cmodel-medium))
>> >   CFLAGS-.oS += -mcmodel=medium
>> >   endif
>> > +
>> > +# Make _dl_tlsdesc_dynamic slow path less expensive by denying __tls_get_addr
>> > +# from using any FPR.
>> > +#
>> > +# Attention: if you see an ICE here, it's likely __tls_get_addr is doing
>> > +# something wrong: why should it do floating-point operations anyway?!
>> > +# Please fix it instead of complain to GCC maintainers.
>> > +ifeq (yes,$(have-mno-lsx))
>> > +CFLAGS-libc-tls.c += -mno-lsx
>> > +endif
>> 
>> This is not correct: __tls_get_addr may call malloc, and an interposed
>> malloc is free to use the full register file.  You need to perform a
>> context switch here, similar to what the lazy binding trampoline does.
>
> Alright, but then do we need to save and restore fcsr and fcc as well? 
> AFAIK they should be saved during a context switch, and AFAIK there are
> no rules saying "interposed malloc cannot alter floating-point execution
> environment".

Sorry, I'm not familiar with those register names and floating point
matters.

That being said, I don't think malloc may change the rounding mode and
other floating point environment aspects.  Not sure about raising
exceptions, though.

Thanks,
Florian



More information about the Libc-alpha mailing list