[lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

[Iain Sandoe]

> On 15 Jan 2024, at 15:35, Florian Weimer <fweimer at redhat.com> wrote:
> 
> * Carlos O'Donell:
> 
>> I agree. TLS should be seen more like .bss/.data rather than something
>> that is allocated with malloc().
> 
> There wasn't consensus regarding this in 2014.  See below.
> 
>> If we leak memory via TLS that is a glibc bug that we can deal with,
> 
> This is something that libgcc_s.so.1 does in GCC 14 if the heap
> trampolines are used.

Is there a GCC BZ for this?
(if there is something we should address in GCC, it would be better sooner)

Iain


>> but making it easier to find glibc bugs is also a benefit to the
>> community, but not as valuable a benefit as making TLS correctly
>> async-signal safe.
>> 
>> Likewise we need to discuss when the memory is allocated, regardless
>> of which allocator is used, including allocation up-front at dlopen()
>> time.
>>> [1] https://sourceware.org/pipermail/libc-alpha/2014-January/047931.html
> 
> The change conflated multiple issues: sanitizer support,
> async-signal-safe TLS access, and eager allocation of all TLS-related
> memory, so that subsequent accesses cannot fail.  My impression was the
> main point of contention was eager allocation because it was perceived
> as a breaking semantic change.  Nowadays, as long as we are willing to
> maintain both allocator variants, we could offer a choice between them
> controlled by a tunable.  For sanitizer compatibility, we could perform
> eager allocation using malloc.  It's probably a good idea to do it this
> way anyway because a separate mmap-based allocator would increase TLB
> pressure.
> 
> Thanks,
> Florian
>