[PATCH v4] nptl: Add <thread_pointer.h> for RISC-V

Palmer Dabbelt palmer@rivosinc.com
Thu Oct 17 20:46:55 GMT 2024


On Thu, 17 Oct 2024 12:57:54 PDT (-0700), fw@deneb.enyo.de wrote:
> * Michael Jeanson:
>
>> On 2024-10-16 17:16, Michael Jeanson wrote:
>>> This will be required by the rseq extensible ABI implementation on all
>>> Linux architectures exposing the '__rseq_size' and '__rseq_offset'
>>> symbols to set the initial value of the 'cpu_id' field which can be used
>>> by applications to test if rseq is available and registered. As long as
>>> the symbols are exposed it is valid for an application to perform this
>>> test even if rseq is not yet implemented in libc for this architecture.
>>>
>>> A cleaner solution for the fallback code would be to use a global
>>> 'register' variable, unfortunatly 'tls.h' a non-installed header already
>>> defines '__thread_self' for the 'tp' register and GCC doesn't accept
>>> multiple global register variables for the same register.
>>
>> Would it make more sense to move the global register variable '__thread_self'
>> to the new 'thread_pointer.h' header and then include it in 'tls.h'?
>
> I think we should not define a global register value in an installed
> header because it may be in conflict with what the application is
> doing.

That seems reasonable to me.  The fallback inline asm doesn't seem all 
that ugly, so as long as it works everywhere I'm good with it.  Thus

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

Thanks!

On a related note: Our internal_syscallN() macros have a similar flavor 
of local inline asm, I'm not sure if we're going to end up with a 
similar clang-related bug over there?

I also filed https://github.com/llvm/llvm-project/issues/112773 , as I 
couldn't find it anywhere else.

> Hopefully this will be irrelvant some day because every compiler in
> use supports__builtin_thread_pointer.


More information about the Libc-alpha mailing list