[PATCH] Use TLS initial-exec model for __libc_tsd_* thread variables

[Jens Remus]

Hello Florian!

On 7/31/2025 4:31 PM, Jens Remus wrote:
> On 7/31/2025 12:01 PM, Florian Weimer wrote:

>> So with the wider context, we have two separate but related issues here:
>>
>> (1) Specifying the initial-exec TLS model using the GCC attribute results
>>     in a pessimization for static builds.  This prevents GCC from using
>>     the local-exec model directly, relying on linker relaxation instead.
> 
> How is Jakub's statement [1] regarding the attribute on declaration/
> definition to be understood?  Must the attribute match between
> declaration and definition of a variable?  Or must it match between all
> declarations and definitions of all variables?  In the former case the
> attribute is currently erroneously missing on the definition.
> 
> IOW is the fix to add the missing attribute to the definition or to remove
> it from the declaration?

Just to clarify:  Stefan's internal testing surfaced that your
refactoring resulted in a potential regression, which showed up as test
failure on s390 32-bit and different code on x86.  My patch is a naive
attempt to restore the previous behavior, without me being able to tell
whether that is the right thing to do.  For s390 32-bit the patch is not 
strictly required, as the GNU linker has been fixed with Binutils 2.41.

Unless Jakub's statement is to be understood that attributes on
declaration and definition must match, there may not be a need to do
anything.

>> (2) An issue when relaxing initial-exec TLS to local-exec TLS in the S390
>>     link editor.
>>
>> It's not clear to me how the proposed patch fixes (2).  Does it stop the
>> optimization from happening?  I'm okay with applying this as a
>> workaround, given that it makes TLS usage more consistent.
> > On s390 32-bit VARIANT=2 and 4 result in the following for ppbar, which
> I have chosen as it shows the issue pretty clear.  Reduced to the
> relevant assembler statements (omitting most directives).
> 
> VARIANT=2 results in:
> 
> ppbar:
> 	larl	%r5,.L12
> 	l	%r1,.L13-.L12(%r5)
> 	ear	%r2,%a0
> 	ar	%r2,%r1
> 	br	%r14
> 	.section	.rodata
> .L12:
> .L13:
> 	.long	.LANCHOR0@NTPOFF+4   <-- offset to pbar of +4 in relocation addend

Note that on RHEL 7.9 with GCC 4.8.5 the generated code for VARIANT=2
does not make use of a relocation addend and therefore does not trigger
the linker bug.  Stefan's test and my samples above were from Fedora 37
with GCC 12.2.1.

>> Eventually, we should use local-exec TLS for libc.a, addressing (1).
>> I hope it won't bring back the S390 bug.

Given the GNU linker fix in Binutils 2.41 this should not be an issue.

> [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294#c18
>      (via https://sourceware.org/bugzilla/show_bug.cgi?id=33234#c3)
Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/