errno/h_errno

[H. Peter Anvin]

On June 23, 2025 11:09:14 PM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>* Wilco Dijkstra:
>
>>> I agree, and for the unlikely case where dlmopen is used we have
>>> glibc.rtld.optional_static_tls to overcome possible issues.
>>
>> Couldn't that be automatic for large TLS in dlmopen? Also why don't we
>> have a glibc.rtld.static_tls=N tunable for static TLS reservation? Then only
>> applications which use dl(m)open with large TLS sizes would need to pay
>> the price of reserving extra memory per thread, but they will still benefit
>> from the low overhead of static TLS.
>
>There is a potential future where dlmopen is not on obscure interface,
>but a basic compositional tool used to avoid accidental symbol
>interposition.  But these separate namespaces may not actually need
>separate libcs (and can share errno, malloc etc.), so perhaps
>initial-exec references to errno are not an obstacle to that.
>
>But the DF_STATIC_TLS flag issue remains.
>
>Thanks,
>Florian
>

Right, I was talking specifically about libc here, being such a low-level fundamental component.