https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
Bug ID: 96200
Summary: Implement __builtin_thread_pointer() and
__builtin_set_thread_pointer() if TLS is supported
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: carlos at redhat dot com
Target Milestone: ---
In glibc we implement the equivalent of __builtin_thread_pointer() and
__builtin_set_thread_pointer() to access data that is at a constant offset from
the thread pointer.
For many of the architectures that have the builtins their tls.h implementation
in glibc is greatly simplified because they can use the builtin.
We have some ABIs that are defined as having data of a certain size and
alignment at a fixed offset from the thread pointer e.g. stack_guard,
pointer_guard, TM ABI, __private_ss (split stack) etc.
In relation to restartable sequences in the linux kernel it was discussed that
it might be interesting to have an ABI that also uses TP + offset, where glibc
provides the "offset" via an API, but the user is left to do the "TP + offset"
calculation on their own.
https://lore.kernel.org/linux-api/2452161.11491.1594732791558.javamail.zim...@efficios.com/
"Is there an arch-agnostic way to get the thread pointer from user-space code ?
That would be needed by all rseq critical section implementations."
We should support these two builtins for all targets that support TLS.
