linux-openrisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Michael Jeanson <mjeanson@efficios.com>
Cc: Linux OpenRISC <linux-openrisc@vger.kernel.org>,
	GLIBC patches <libc-alpha@sourceware.org>
Subject: Re: [PATCH] nptl: Add <thread_pointer.h> for or1k
Date: Mon, 6 Jan 2025 20:18:19 +0000	[thread overview]
Message-ID: <Z3w6iz3oo7JCoU_z@antec> (raw)
In-Reply-To: <9dfd2255-12fe-48ba-a6cd-43956a08e685@efficios.com>

On Mon, Jan 06, 2025 at 01:26:48PM -0500, Michael Jeanson wrote:
> On 2024-12-24 15:20, Stafford Horne wrote: 
> > I think this ended up being ok.
> > 
> > I have added the call to rseq_syscall and implemented self tests on my branch
> > now.
> > 
> >  - https://github.com/stffrdhrn/linux/commits/or1k-rseq/
> >  - commit 1fa73dd6c2d3 ("rseq/selftests: Add support for OpenRISC")
> > 
> > I haven't got the tests to complete fully yet though.  Do you have a recommended
> > approach for building, testing and debugging them?  I am using my glibc
> > toolchain, but I assume the original implementations didnt have glibc support
> > available when they were testing.
> > 
> > My stack now:
> > 
> >   - QEMU virt
> >   - Linux virt_defconfig (or1k-rseq branch)
> >     - rseq selftests - built with gcc/glibc toolchain (or1k-rseq branch)
> >   - rootfs - Buildroot with my glibc (or1k-rseq branch)
> >     - gdb
> >     - strace
> > 
> > In general I am using the latest git HEADs for qemu, gcc, binutils etc.
> > 
> > Once, everything is working on QEMU I will test again on the FPGA hardware.
> > 
> > Currently tests are failing with SIGSEGV:
> > 
> >     TAP version 13
> >     1..10
> >     # timeout set to 0
> >     # selftests: rseq: basic_test
> >     # testing current cpu
> >     ok 1 selftests: rseq: basic_test
> >     # timeout set to 0
> >     # selftests: rseq: basic_percpu_ops_test
> >     # spinlock
> >     # ./kselftest/runner.sh: line 37:   772 Segmentation fault      /usr/bin/timeout  --foreground "$kselftest_timeout" /usr/bin/timeout "$kselftest_timeout" $1
> >     not ok 2 selftests: rseq: basic_percpu_ops_test # exit=139
> > 
> > In gdb it looks to be happening in in an mprotect syscall in glibc and at that
> > point the stack seems to be corrupt already.  So its taking me a bit of time to
> > untangle.
> > 
> > -Stafford
> 
> Hi,
> 
> Sorry for the late reply, I was away for the holidays. From your other message I
> think you managed to get through this. Is there anything I can still help you
> with?

No problem,

I figured you were on vacation.  I just kept sending mails to document my
progress.  The holiday's are when I get the most time to work on this stuff.

As of now there is nothing else needed.

-Stafford

  reply	other threads:[~2025-01-06 20:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20241101192339.123141-1-mjeanson@efficios.com>
     [not found] ` <20241101192339.123141-5-mjeanson@efficios.com>
     [not found]   ` <ZzJ-T-5VFZ8gZEf7@antec>
     [not found]     ` <94aee33f-c9d2-428b-9b03-7e4fb1c97472@efficios.com>
     [not found]       ` <Z1g2UxaMlKH5o5nc@antec>
     [not found]         ` <Z1h5hzWpD8Fu77AL@antec>
     [not found]           ` <8dcf9b95-b7fb-4b5e-8708-b4428b58ecd1@efficios.com>
     [not found]             ` <8afa2c34-9416-412d-9920-ab15b44c6d4b@efficios.com>
     [not found]               ` <Z1rZ6APG2ViLdLmy@antec>
     [not found]                 ` <e249789e-0cfa-4d66-805b-e3cd1aef957a@efficios.com>
2024-12-14 11:03                   ` [PATCH] nptl: Add <thread_pointer.h> for or1k Stafford Horne
2024-12-24 20:20                     ` Stafford Horne
2025-01-02  1:08                       ` Stafford Horne
2025-01-05  6:48                         ` Stafford Horne
2025-01-06 15:44                           ` Michael Jeanson
2025-01-06 18:26                       ` Michael Jeanson
2025-01-06 20:18                         ` Stafford Horne [this message]
2025-01-06 20:32                           ` Michael Jeanson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z3w6iz3oo7JCoU_z@antec \
    --to=shorne@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-openrisc@vger.kernel.org \
    --cc=mjeanson@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).