Re: [PATCH] Reserve static TLS for dynamically loaded initial-exec TLS only [BZ #25051]

[Szabolcs Nagy <Szabolcs.Nagy@arm.com>]

On 07/01/2020 12:09, Florian Weimer wrote:
> * Szabolcs Nagy:
> 
>> This patch reserves 128 bytes of the surplus TLS that is not used
>> opportunistically. TLS_STATIC_SURPLUS is currently 1664, so this still
>> allows 1536 bytes for opportunistic use. A new test is added to verify
>> this ABI contract: dynamic loading of libraries with initial-exec TLS
>> is supported up to 128 bytes in total on all targets. This should be
>> enough for system libraries such as libgomp.
> 
> I'm not sure if it's enough for loading another libc.so.6 via dlmopen.
> Have you tested this, by chance?

i haven't tested, but that wont work reliably with
this patch.

libc.so on aarch64 has 144 byte TLS (8byte alignmed),
so the reserved 128byte surplus TLS is not enough
(can be increased to 144 though).

however if a lib with ie TLS is loaded before the static
TLS runs out then that works: the 128byte reserve will be
kept available until the 'opportunistic' part of TLS runs
out and then the reserve can only be used for ie TLS.
(so early dlmopen of libc.so.6 and later dlopen of libgomp
works)

this may not be an ideal solution: if all the ie TLS libs
are loaded early then reserving 128 byte at the end is not
that useful.

but using dlmopen to load multiple instances of libc and
libgomp and libopengl etc will not work reliably because
we can't keep enough static TLS reserve for that: if that's
the preferred behaviour then glibc should not use static
TLS opportunistically for TLSDESC and ppc TLS opt.