From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 518D92B8B8 for ; Sun, 18 Feb 2024 16:48:48 +0100 (CET) Received: (qmail 31846 invoked by uid 550); 18 Feb 2024 15:45:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20291 invoked from network); 18 Feb 2024 15:03:47 -0000 Date: Sun, 18 Feb 2024 18:06:46 +0300 From: Valery Ushakov To: musl@lists.openwall.com, toybox Message-ID: References: <349f4e17-8027-c521-eeb3-aa69e8f2b5a4@landley.net> <20240218013428.GJ4163@brightrain.aerifal.cx> <20240218014049.GK4163@brightrain.aerifal.cx> <20240218143312.GL4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240218143312.GL4163@brightrain.aerifal.cx> Subject: Re: [musl] 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