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

[H.J. Lu]

On Wed, Jul 30, 2025 at 8:22 AM Jens Remus <jremus@linux.ibm.com> wrote:
>
> One or more of the following files ( sample.sh ) violates IBM policy and all attachment(s) have been removed from the message.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Please open a glibc bug report with your test.

> **********************************************************************
> Hello Florian!
>
> On 7/29/2025 4:03 PM, Florian Weimer wrote:
> > * Jens Remus:
> >
> >> Commit 10a66a8e421b ("Remove <libc-tsd.h>") removed the TLS initial-exec
> >> (IE) model attribute from the __libc_tsd_* thread variable declarations
> >> and definitions.  Commit a894f04d8776 ("Optimize __libc_tsd_* thread
> >> variable access") restored it on declarations.
> >>
> >> Restore the TLS initial-exec model attribute on __libc_tsd_* thread
> >> variable definitions.
> >>
> >> This resolves test tst-locale1 failure on s390 32-bit, when using a
> >> GNU linker without the fix from GNU binutils commit aefebe82dc89
> >> ("IBM zSystems: Fix offset relative to static TLS").
> >>
> >> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> >> ---
> >>
> >> Notes:
> >>     Even though compiler option -ftls-model=initial-exec is used, the
> >>     explicit specification of __attribute__ ((tls_model ("initial-exec")))
> >>     on thread variable definitions (not declarations) has an effect on the
> >>     code emitted by GCC for s390 32-bit.
> >>
> >>  ctype/ctype-info.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/ctype/ctype-info.c b/ctype/ctype-info.c
> >> index b7d3422726f5..fb5acf9419db 100644
> >> --- a/ctype/ctype-info.c
> >> +++ b/ctype/ctype-info.c
> >> @@ -24,11 +24,11 @@
> >>     __ctype_init before user code runs, but this does not happen for
> >>     threads in secondary namespaces.  With the initializers, secondary
> >>     namespaces at least get locale data from the C locale.  */
> >> -__thread const uint16_t * __libc_tsd_CTYPE_B
> >> +__thread const uint16_t * __libc_tsd_CTYPE_B attribute_tls_model_ie
> >>    = (const uint16_t *) _nl_C_LC_CTYPE_class + 128;
> >> -__thread const int32_t * __libc_tsd_CTYPE_TOLOWER
> >> +__thread const int32_t * __libc_tsd_CTYPE_TOLOWER attribute_tls_model_ie
> >>    = (const int32_t *) _nl_C_LC_CTYPE_tolower + 128;
> >> -__thread const int32_t * __libc_tsd_CTYPE_TOUPPER
> >> +__thread const int32_t * __libc_tsd_CTYPE_TOUPPER attribute_tls_model_ie
> >>    = (const int32_t *) _nl_C_LC_CTYPE_toupper + 128;
> >
> > It's weird that the declaration in include/ctype.h is not applied by the
> > compiler (and neither is the command line option).  Isn't this a
> > compiler bug?
>
> GCC on x86-64 does also generate different output depending on whether
> the attribute is specified in the variable definition or not in addition
> to the compiler option.  The specification of the attribute in the
> variable declaration does not have an effect - at least on the emitted
> assembler source.
>
> Attached is a small sample.  Following are excerpts from b.s variants
> reduced to the relevant assembler statements:
>
> # gcc option only:
> $ VARIANT=2 ./sample.sh
> $ cat b.s   # excerpt reduced to assembler statements
> ...
> ppfoo:
>         leal    pfoo@ntpoff, %eax
>         addl    %gs:0, %eax
>         ret
>
> # gcc option and attribute in variable declaration (same as previous):
> $ VARIANT=3 ./sample.sh
> $ cat b.s   # excerpt reduced to assembler statements
> ...
> ppfoo:
>         leal    pfoo@ntpoff, %eax
>         addl    %gs:0, %eax
>         ret
>
> # gcc option and attribute in variable declaration and definition:
> $ VARIANT=4 ./sample.sh
> $ cat b.s   # excerpt reduced to assembler statements
> ...
> ppfoo:
>         call    __x86.get_pc_thunk.ax
>         addl    $_GLOBAL_OFFSET_TABLE_, %eax
>         movl    pfoo@gotntpoff(%eax), %eax
>         addl    %gs:0, %eax
>         ret
>
> This is way above my head.  Please feel free to investigate and/or open
> a bug against GCC.  I'll be away from keyboard for a few weeks.
>
> > I'm okay with this as a workaround.
> >
> > Reviewed-by: Florian Weimer <fweimer@redhat.com>
>
> Thanks you!  Stefan would take care to commit during my leave, provided
> there are no objections.
>
> Thanks and 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/



-- 
H.J.