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

[Joseph Myers]

On Mon, 15 Jan 2024, Florian Weimer via Gcc wrote:

> 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.

Related to eager allocation is the question of whether libgcc_s.so.1 
should be loaded unconditionally by glibc at startup - doing so has much 
the same motivation (avoiding subsequent failures from interfaces that 
don't have any good way to signal failure, when glibc currently loads 
libgcc_s.so.1 dynamically), but also no doubt compatibility risk.

-- 
Joseph S. Myers
josmyers at redhat.com