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

[Stafford Horne <shorne@gmail.com>]

+CC Lists,

They should have been included for all of these.

On Fri, Dec 13, 2024 at 11:22:32AM -0500, Michael Jeanson wrote:
> On 2024-12-12 07:41, Stafford Horne wrote:
> > On Tue, Dec 10, 2024 at 03:30:05PM -0500, Michael Jeanson wrote:
> >> On 2024-12-10 13:56, Michael Jeanson wrote:
> >>>> 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.
> >>>
> >>> Do you have a WIP tree somewhere I can have a look at? Assuming you add
> >>> HAVE_REGS_AND_STACK_ACCESS_API, the rest should be pretty simple.
> >>
> >> I had a quick look at the kernel code and it looks pretty straightforward,
> >> I hacked this together just to see if it would build :
> >>
> >>   https://github.com/mjeanson/linux/commits/openrisc-rseq/
> >>
> >> This is thoroughly untested and only cross-compiled.
> > 
> > Thanks, while you were doing this I did something similar but took a much
> > shorter route, I only implemented the APIs used by rseq.
> > 
> > I have pushed branches for linux and glibc here:
> > 
> >  - https://github.com/stffrdhrn/or1k-glibc/commits/or1k-rseq/
> >  - https://github.com/stffrdhrn/linux/commits/or1k-rseq/
> 
> You might also want to add a call to 'rseq_syscall' in arch/openrisc/kernel/entry.S
> on return to userspace when CONFIG_DEBUG_RSEQ is enabled.

Yes, I am aware of that one, but I think I discovered an issue with the return to
userspace code that needs some cleanup before I can add that in.

> > 
> > With these the glibc tests for rseq do work on openrisc, see output below.  Do
> > you think with proper cleanups the glibc tests only would be enough to push this
> > upstream? As I haven't started writing the linux selftests for rseq.
> 
> It would really be better to implement the selftests, the current glibc test only
> do registration of the rseq area, there is no critical section / functional tests
> of the rseq feature.
> 
> This is something me and Mathieu could assist you with, first adding support for
> openrisc in librseq [1] and then we mostly just have to copy the headers to the
> kernel selftests to add support.
> 
> I can do most of the boilerplate of adding the architecture but you would be
> better suited to write the assembly used in the critical sections.

OK, I think I can add the boilerplace too by copying from another architecture.
Thanks for the tip on using librseq. I was looking at this code earlier today.

> Do you have access to hardware you could share temporarily for testing?

I have been doing most of my testing with qemu-system-or1k, built from source.
I run the virt platform which boots with Linux virt_defconfig.  The filesystem I
run is a setup from builtroot [1].

For "real" harware I have run OpenRISC in litex [2] on FPGA boards.  There is no
real hardware that I have access too.  The QEMU system emulator is the fastest
though so I have been using that almost exclusively lately.

-Stafford

[1] https://github.com/stffrdhrn/or1k-utils/tree/master/buildroot
[2] https://github.com/enjoy-digital/litex