[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261004150815.GH23438@brightrain.aerifal.cx>
Date: Sun, 4 Oct 2026 11:08:15 -0400
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>,
musl@...ts.openwall.com
Subject: Re: [PATCH] riscv: declare all vector registers as clobbers
of syscalls
On Sun, Oct 04, 2026 at 02:21:35PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.net> [2026-10-04 12:55:13 +0200]:
> > * Alex Rønne Petersen <alex@...xrp.com> [2026-10-04 04:48:52 +0200]:
> > > The kernel intentionally clobbers vector registers (by setting them to all 1s).
> > > musl didn't declare this, so with a compiler targeting the V extension, this
> > > could lead to all sorts of breakage that at first glance looks like
> > > miscompilations.
> >
> > for the record the aarch64 behaviour is keeping the
> > normal parts of the simd regs and zeroing the sve
> > extension bits.
> >
> > https://www.kernel.org/doc/html/latest/arch/arm64/sve.html#system-call-behaviour
> >
> > so current musl clobber is wrong when compiled with +sve
> > (note: "cc" is actually preserved not clobbered)
> >
> > test to demonstrate:
> > https://godbolt.org/z/xKfozYzjj
>
> i dont see a clean solution to the d8..d15 problem:
> these are call preserved fp regs so a clobber on the
> overlapping sve z8..z15 spills them, the kernel clobbers
> the top bits only but i dont see asm syntax for that.
>
> either we explicitly build musl as +nosve or make
> the syscalls noinline when building with sve
> (normal call convention clobbers top bits of sve regs)
Is there any way musl could plausibly be using upper range of sve
registers? This is probably at present only a theoretical problem, but
I think we should fix it. Forcing nosve seems like the clean solution,
but I'm not sure that helps in a theoretical case where someone is
using LTO and the compiler tries to inline code from inside musl
across other functions in musl (nosve) into a calling application
(using sve). The only solution here short of fixing the badly designed
compiler asm constraints might be forcing noinline if built to support
LTO.
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.
