[PATCH v16 5/8] nptl: Introduce <rseq-access.h> for RSEQ_* accessors

[Frank Scheiner]

Dear Michael,

On 13.01.25 20:11, Michael Jeanson wrote:
> On 2025-01-13 05:49, Frank Scheiner wrote:
>> The changes in 494d651 ([1]) break our ia64 toolchain builds as it
>> looks like ia64 is one of (or) the (only) arch(es) w/o
>> __builtin_thread_pointer() in the GCC:
>>
>> ```
>> In function '__thread_pointer',
>>     inlined from 'RSEQ_SELF' at ../sysdeps/unix/sysv/linux/rseq-internal.h:93:41,
>>     inlined from '__pthread_create_2_1' at pthread_create.c:699:13:
>> ../sysdeps/generic/thread_pointer.h:25:10: error: '__builtin_thread_pointer' is not supported on this target
>>    25 |   return __builtin_thread_pointer ();
>>       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ```
>>
>> [1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=494d65129ed5ae1154b75cc189bbdde5e9ecf1df
>
> Do you maintain a private ia64 port in a separate branch/repo?

Yeah, sort of. Mainly trying... ;-)

You can find the repo here:

https://github.com/linux-ia64/glibc-ia64/

We're actually a group of people and we also maintain Linux for ia64 out
of tree - as a matter of fact both since over a year now.

Well, we can't do w/o a kernel and a libc for the two distributions that
still support ia64, can we. (-:

More details about the whole effort can be found on:

http://epic-linux.org/

>> This seems to indeed "fix" the ia64 build for me, I just don't really know if
>> it is fully correct to use __thread_self like that:
>>
>> ```
>> register struct pthread *__thread_self __asm__("r13");
>>> static inline void *
>> __thread_pointer (void)
>> {
>>   return __thread_self;
>> }
>> ```
>>
>> But I guess a pointer is a pointer and the compiler seems to be happy,
>> too.
>
> Your patch should work as-is, some compilers might warn on the implicit
> cast to 'void *' but you can just add the explicit cast in __thread_pointer().

Thanks for the confirmation.

I also documented this issue in the meantime on [2].

[2]: https://github.com/linux-ia64/glibc-ia64/issues/8#issuecomment-2588226464

I actually did try with explicit cast first but the used gcc (should be
gcc-15-20250105 or [...]12) also didn't warn w/o, but that was maybe
due to the gcc command line used by the T2 build system - IDK for sure.

I left the explicit cast out for now as it's done implicitly anyhow. Or
is that considered bad practice? But it can always be changed later.

Cheers,
Frank