[PATCH] nptl: Add <thread_pointer.h> for or1k

[Stafford Horne]

On Tue, Dec 10, 2024 at 12:38:43PM +0000, Stafford Horne wrote:
> On Mon, Dec 09, 2024 at 02:19:15PM -0500, Michael Jeanson wrote:
> > On 2024-11-11 16:59, Stafford Horne wrote:
> > > On Fri, Nov 01, 2024 at 03:23:24PM -0400, 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.
> > >>
> > >> Compile tested with build-many-glibcs.py but I don't have access to any
> > >> hardware to run the tests.
> > > 
> > > Hello,
> > > 
> > > Thanks for this.  I am away on a long business trip so not having much time to
> > > work on this right now.  I will be back next week and Ill get some time to sit
> > > down and test this.
> > > 
> > > I will push the commit if all looks and works fine.  At the moment OpenRISC
> > > doesn't have support for rseq, I started adding support for it a while ago but
> > > didn't finish as the in kernel testing suite was taking too long to get setup.
> > > Now that there is support in glibc it should be much easier to test the linux
> > > support.
> > > 
> > > So, thanks a lot for this.
> > > 
> > > -Stafford
> > 
> > Ping? If you need help with enabling rseq in the kernel don't hesitate to reach
> > out.
> 
> Sorry, I haven't forgot about this.  But I had some kernel and qemu patches to
> work though and test first.  I will get to this over the next week, I am
> building a new glibc and starting testing now.

Hi Michael,

I built this patch and ran all the tests under `nptl` with no issues.  However,
looking at the code I don't thinl the __thread_pointer function will be tested
unless we define RSEQ_SIG, is that right?

Is there any other way to test this right now without rseq?

I started adding rseq support to OpenRISC, but it seems I need to do a bit more
for me than just call rseq_signal_deliver().  OpenRISC does not implement
HAVE_REGS_AND_STACK_ACCESS_API yet, so I will need to do that first.  Also I
need to think of an instruction to use for RSEQ_SIG, but that should not be too
hard.

-Stafford