[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