[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdIdBj000y2-RpOS@snips.stderr.spb.ru>
Date: Sun, 18 Feb 2024 18:06:46 +0300
From: Valery Ushakov <uwe@...err.spb.ru>
To: musl@...ts.openwall.com, toybox <toybox@...ts.landley.net>
Subject: Re: Re: Not sure how to debug this one.
On Sun, Feb 18, 2024 at 09:33:13 -0500, Rich Felker wrote:
> On Sun, Feb 18, 2024 at 03:55:36PM +0300, Valery Ushakov wrote:
> > On Sat, Feb 17, 2024 at 20:40:50 -0500, Rich Felker wrote:
> >
> > > due to incorrect base address register when attempting to reload the
> > > saved value of r8, the caller's value of r8 was not preserved.
> > > ---
> > > src/signal/sh/sigsetjmp.s | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/src/signal/sh/sigsetjmp.s b/src/signal/sh/sigsetjmp.s
> > > index 1e2270be..f0f604e2 100644
> > > --- a/src/signal/sh/sigsetjmp.s
> > > +++ b/src/signal/sh/sigsetjmp.s
> > > @@ -27,7 +27,7 @@ __sigsetjmp:
> > >
> > > mov.l 3f, r0
> > > 4: braf r0
> > > - mov.l @(4+8,r4), r8
> > > + mov.l @(4+8,r6), r8
> > >
> > > 9: mov.l 5f, r0
> > > 6: braf r0
> >
> > That takes care of restoring caller's r8 for the first return from
> > sigsetjmp, but isn't there still the problem that the jump buffer
> > contains the wrong one, so on the second return from sigsetjmp the
> > caller will have clobbered r8?
> >
> > Sorry for a drive-by reply. I'll try to take a closer look in the
> > evening.
>
> No, that's the return path for both returns.
>
> The whole reason a call-saved register like r8 is used here is so
> that we can return twice into the body of sigsetjmp, in order to
> tailcall __sigsetjmp_tail at both the first return and subsequent
> return.
Doh, right! Sorry. A comment to that effect to alert the reader
would certainly have helped :) Neat trick that I missed on the quick
reading.
> This is what makes it possible to restore the signal mask from the
> returned-to frame rather than the returning-from frame (which is why
> the attached doesn't crash with stack overflow on musl like it does
> on glibc).
Restoring the context in siglongjmp should not be a problem per-se.
NetBSD libc does that and the example code doesn't crash there (quick
unscientific test on a ppc that I happen to have a terminal open on).
But then NetBSD libc doesn't bother to carefully factor that code to
minimize the need for MD asm.
Thanks, and sorry for the noise.
-uwe
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
