Comment 40 for bug 1375555

(In reply to Arkadiusz Miskiewicz from comment #31)
> (In reply to Carlos O'Donell from comment #25)
>
> > After an analysis I see ~44 distribution-wide libraries using static TLS,
>
> Could you tell us how to see/check which libraries are affected?

All architectures should set the STATIC_TLS flag in the dynamic section if any variable used static TLS. Some architectures, AArch64 I believe, fail to set STATIC_TLS (a bug), but in that case you can see the static tls usage by the relocation.

e.g.

[carlos@koi static-tls]$ readelf -a -W /lib64/libc.so.6 | grep STATIC
 0x000000000000001e (FLAGS) BIND_NOW STATIC_TLS

OK, because libc.so.6 uses static TLS to accelerate the runtime.

[carlos@koi lib64]$ readelf -a -W libGL.so.1.2.0 | grep STATIC
 0x000000000000001e (FLAGS) SYMBOLIC STATIC_TLS

Technically not OK because libGL is not part of the core runtime, but as a distribution we are coordinating the use of static TLs across multiple libraries to accelerate the distribution.

[carlos@koi lib64]$ readelf -a -W libGL.so.1.2.0 | grep TPOFF
0000003f66e91fb8 0000000000000012 R_X86_64_TPOFF64 0
0000003f66e91ff0 000000ab00000012 R_X86_64_TPOFF64 0000000000000000 _glapi_tls_Dispatch + 0

If on x86_64 the STATIC_TLS would not have been set, we could have looked for thread-pointer offset relocations to catch the use of static TLS. Here you can see that the libGL variable `_glapi_tls_Dispatch` is using static TLS and has a TPOFF relocation to have the dynamic loader setup the variable properly during assembly of the in-memory application execution image.