Re: [PATCH 1/8] nptl: Add <thread_pointer.h> for defining __thread_pointer

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

The 12/08/2021 18:55, Florian Weimer wrote:
> * Szabolcs Nagy:
> > The 12/07/2021 14:00, Florian Weimer via Libc-alpha wrote:
> >> <tls.h> already contains a definition that is quite similar,
> >> but it is not consistent across architectures.
> >> 
> >> Only architectures for which rseq support is added are covered.
> >
> > This looks ok.
> >
> > It's an annoying gcc bug that __builtin_thread_pointer
> > does not work consistently across targets.
> >
> > Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
> 
> We don't need m68k for rseq, so I haven't added it, but I saw that
> __thread_pointer is actually a system call there.  Maybe that's why it's
> not a universal GCC feature.  Furthermore, for many ABIs, the thread
> pointer is somewhat implicit.  On x86, it took some discussion to figure
> out that we actually have a canonical notion of a thread pointer.  On
> some other targets, the thread pointer is stored explicitly in a
> (system) register, but it actually points to nowhere, so that local-exec
> TLS access can make better use of immediate instruction operands.

i think local-exec tls access has to expose
some notion of thread pointer to the compiler
(from which a tls variable is at fixed offset).

whatever that notion is, __builtin_thread_pointer
can be defined based on that and if there is
nothing exposed then presumably tls access
relies on libc apis so __builtin_thread_pointer
can also rely on a libc api (or syscall).

tp is useful as a thread identifier and for fixed
offset tcb abis. (especially within libc and
compiler runtimes)

> 
> It's also annoying that __has_builtin (__builtin_thread_pointer)
> evaluates to true even for GCC targets where actually using
> __builtin_thread_pointer () results in a compiler error.
> 
> In the future, we could install this as <sys/thread_pointer.h> if people
> think it's useful (not just in an rseq context).

yeah, i would prefer gcc to be fixed.