Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250222015200.GL1827@brightrain.aerifal.cx>
Date: Fri, 21 Feb 2025 20:52:00 -0500
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v2] clone: clear the frame pointer in the child
 process on relevant ports

On Sat, Feb 22, 2025 at 02:32:45AM +0100, Alex Rønne Petersen wrote:
> On Sat, Feb 22, 2025 at 2:06 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Thu, Dec 12, 2024 at 05:56:04PM +0100, Alex Rønne Petersen wrote:
> > > This just mirrors what is done in the start code for the affected ports, as well
> > > as what is already done for the three x86 ports.
> > >
> > > Clearing the frame pointer helps protect FP-based unwinders which have no way of
> > > knowing that the FP register should be considered undefined in the child process
> > > portion of clone(). In practice, we found this change to be necessary when
> > > running the Zig standard library tests under qemu-aarch64_be with musl linked.
> > >
> > > This version of the patch omits the branch inversion on x86 and powerpc from the
> > > previous version, per the discussion there.
> >
> > Trying to apply this, but...
> >
> > > diff --git a/src/thread/m68k/clone.s b/src/thread/m68k/clone.s
> > > index f6dfa06f..42ec19f7 100644
> > > --- a/src/thread/m68k/clone.s
> > > +++ b/src/thread/m68k/clone.s
> > > @@ -18,7 +18,8 @@ __clone:
> > >       beq 1f
> > >       movem.l (%sp)+,%d2-%d5
> > >       rts
> > > -1:   move.l %a1,-(%sp)
> > > +1:   suba.l %%fp,%%fp
> > > +     move.l %a1,-(%sp)
> > >       jsr (%a0)
> > >       move.l #1,%d0
> > >       trap #0
> >
> > This does not assemble and is most likely not valid. I get:
> >
> > src/thread/m68k/clone.s:21: Error: operands mismatch -- statement `suba.l %%fp,%%fp' ignored
> >
> > Do you know what the right instruction to use here is for m68k? And,
> > have you tested that the rest of the affected archs build?
> 
> Sorry, this was a silly mistake from copying the code from inline
> assembly in Zig, where % has to be escaped with an extra %. It should
> just simply be suba.l %fp,%fp.

Thanks, that fixed it. I should have read closer...

> Beyond that, I've assembled all of the archs affected here
> successfully, and for those that LLVM supports, they've been tested by
> way of Zig's test suite under QEMU.

OK.

Rich

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.