[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <e401c318-12bd-4810-a841-4b6020e6afd7@app.fastmail.com>
Date: Wed, 04 Nov 2026 10:01:52 +0100
From: "Imre Kaloz" <kaloz@...nel.org>
To: "Rich Felker" <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH 03/10] support archs whose clone indicates the child in a
second return register
Hi Rich,
On Wed, Nov 4, 2026, at 00:54, Rich Felker wrote:
> I don't see how this is motivated at all. Sparc has SYS_fork, so
> SYS_clone will never be used in either of these places.
On sparc fork returns like clone does: the child gets the parent's
pid in %o0 and 1 in %o1, so __syscall(SYS_fork) returns a nonzero
pid in the child. That is why the hook replaces the SYS_fork path as
well; using SYS_clone there was unnecessary, and the message should
have explained the convention.
> And no new
> arch is going to have this kind of wacky calling convention copying a
> legacy proprietary unix.
For v2 I'll keep it in the sparc arch files, with __syscall0 handling
SYS_fork the way s390x handles SYS_mmap and a vfork.s like the
other archs, and drop this patch.
Thanks,
Imre
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.
