errno/h_errno

[Adhemerval Zanella Netto]

On 15/06/25 20:05, H. Peter Anvin wrote:
> On 2025-06-11 08:14, Wilco Dijkstra wrote:
>> Hi Florian,
>>
>>> Initial-exec is only *guaranteed* to work for initially shared objects.
>>> Normally, this includes libc.so.6, so it's safe to use initial-exec.
>>> But it's possible to load multiple copies of libc.so.6 via auditors and
>>> dlmopen, so ideally, libc.so.6 and all the code referencing its TLS
>>> variables should not use initial-exec TLS, either.
>>
>> The amount of IE-TLS in GLIBC is only ~144 bytes. It would be a step back
>> if all thread local variables in GLIBC had to become global-dynamic instead
>> of moving them into the TCB...
>>
>> Given we already use separate builds for static and DSO, could we build
>> GLIBC with different options for dlmopen if needed?
>>
> 
> Let's face it, using glibc in a dlmopen address space is a *very* special case, and one which probably has all kinds of other issues (managing threads and the memory heap, among others.)
> 
> It really seems like a very bad choice to optimize for the rare case like this... and that assumes that one still doesn't want errno to be global to the thread. In so many ways errno is more like a register than anything else.
> 
> This gets all very messy when it comes to semantics no matter how you slice it, but what is *definitely* true is that since (nearly) every single application pulls in glibc, even small optimizations are valuable.

I agree, and for the unlikely case where dlmopen is used we have
glibc.rtld.optional_static_tls to overcome possible issues.