tools/testing/selftests/nolibc/Makefile.nolibc | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Since LLVM commit 39e30508a7f6 ("[Driver][Sparc] Default to -mcpu=v9 for
32-bit Linux/sparc64 (#109278)"), clang defaults to -mcpu=v9 for 32-bit
SPARC builds. -mcpu=v9 generates instructions which are not recognized
by qemu-sparc and qemu-system-sparc. Instead qemu-sparc32plus and
qemu-system-sparc64 with a 64-bit kernel and CONFIG_COMPAT are needed.
Rework the test setup so that -mcpu=v9 also works correctly.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
tools/testing/selftests/nolibc/Makefile.nolibc | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/nolibc/Makefile.nolibc b/tools/testing/selftests/nolibc/Makefile.nolibc
index f9d43cbdc894..18f550c68932 100644
--- a/tools/testing/selftests/nolibc/Makefile.nolibc
+++ b/tools/testing/selftests/nolibc/Makefile.nolibc
@@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig
DEFCONFIG_riscv64 = defconfig
DEFCONFIG_s390x = defconfig
DEFCONFIG_loongarch = defconfig
-DEFCONFIG_sparc32 = sparc32_defconfig
+DEFCONFIG_sparc32 = sparc64_defconfig
DEFCONFIG_sparc64 = sparc64_defconfig
DEFCONFIG_m68k = virt_defconfig
DEFCONFIG_sh4 = rts7751r2dplus_defconfig
@@ -155,7 +155,7 @@ QEMU_ARCH_riscv32 = riscv32
QEMU_ARCH_riscv64 = riscv64
QEMU_ARCH_s390x = s390x
QEMU_ARCH_loongarch = loongarch64
-QEMU_ARCH_sparc32 = sparc
+QEMU_ARCH_sparc32 = sparc64
QEMU_ARCH_sparc64 = sparc64
QEMU_ARCH_m68k = m68k
QEMU_ARCH_sh4 = sh4
@@ -164,6 +164,7 @@ QEMU_ARCH = $(QEMU_ARCH_$(XARCH))
QEMU_ARCH_USER_ppc64le = ppc64le
QEMU_ARCH_USER_mipsn32le = mipsn32el
QEMU_ARCH_USER_mipsn32be = mipsn32
+QEMU_ARCH_USER_sparc32 = sparc32plus
QEMU_ARCH_USER = $(or $(QEMU_ARCH_USER_$(XARCH)),$(QEMU_ARCH_$(XARCH)))
QEMU_BIOS_DIR = /usr/share/edk2/
@@ -195,7 +196,7 @@ QEMU_ARGS_riscv32 = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_T
QEMU_ARGS_riscv64 = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_s390x = -M s390-ccw-virtio -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_loongarch = -M virt -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
-QEMU_ARGS_sparc32 = -M SS-5 -m 256M -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
+QEMU_ARGS_sparc32 = -M sun4u -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_sparc64 = -M sun4u -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_m68k = -M virt -append "console=ttyGF0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_sh4 = -M r2d -serial file:/dev/stdout -append "console=ttySC1,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
---
base-commit: 9d16b22b17ddfd27df1da6088a962a72658f46d1
change-id: 20260104-nolibc-sparc32-fix-42b892ab1c0f
Best regards,
--
Thomas Weißschuh <linux@weissschuh.net>
Hi Thomas,
On Sun, 4 Jan 2026 at 23:14, Thomas Weißschuh <linux@weissschuh.net> wrote:
> Since LLVM commit 39e30508a7f6 ("[Driver][Sparc] Default to -mcpu=v9 for
> 32-bit Linux/sparc64 (#109278)"), clang defaults to -mcpu=v9 for 32-bit
> SPARC builds. -mcpu=v9 generates instructions which are not recognized
> by qemu-sparc and qemu-system-sparc. Instead qemu-sparc32plus and
> qemu-system-sparc64 with a 64-bit kernel and CONFIG_COMPAT are needed.
>
> Rework the test setup so that -mcpu=v9 also works correctly.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Thanks for your patch!
> --- a/tools/testing/selftests/nolibc/Makefile.nolibc
> +++ b/tools/testing/selftests/nolibc/Makefile.nolibc
> @@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig
> DEFCONFIG_riscv64 = defconfig
> DEFCONFIG_s390x = defconfig
> DEFCONFIG_loongarch = defconfig
> -DEFCONFIG_sparc32 = sparc32_defconfig
> +DEFCONFIG_sparc32 = sparc64_defconfig
How can we test sparc32 using a 64-bit kernel?
> DEFCONFIG_sparc64 = sparc64_defconfig
> DEFCONFIG_m68k = virt_defconfig
> DEFCONFIG_sh4 = rts7751r2dplus_defconfig
> @@ -155,7 +155,7 @@ QEMU_ARCH_riscv32 = riscv32
> QEMU_ARCH_riscv64 = riscv64
> QEMU_ARCH_s390x = s390x
> QEMU_ARCH_loongarch = loongarch64
> -QEMU_ARCH_sparc32 = sparc
> +QEMU_ARCH_sparc32 = sparc64
> QEMU_ARCH_sparc64 = sparc64
> QEMU_ARCH_m68k = m68k
> QEMU_ARCH_sh4 = sh4
> @@ -164,6 +164,7 @@ QEMU_ARCH = $(QEMU_ARCH_$(XARCH))
> QEMU_ARCH_USER_ppc64le = ppc64le
> QEMU_ARCH_USER_mipsn32le = mipsn32el
> QEMU_ARCH_USER_mipsn32be = mipsn32
> +QEMU_ARCH_USER_sparc32 = sparc32plus
> QEMU_ARCH_USER = $(or $(QEMU_ARCH_USER_$(XARCH)),$(QEMU_ARCH_$(XARCH)))
>
> QEMU_BIOS_DIR = /usr/share/edk2/
> @@ -195,7 +196,7 @@ QEMU_ARGS_riscv32 = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_T
> QEMU_ARGS_riscv64 = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_s390x = -M s390-ccw-virtio -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_loongarch = -M virt -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> -QEMU_ARGS_sparc32 = -M SS-5 -m 256M -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> +QEMU_ARGS_sparc32 = -M sun4u -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_sparc64 = -M sun4u -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_m68k = -M virt -append "console=ttyGF0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
> QEMU_ARGS_sh4 = -M r2d -serial file:/dev/stdout -append "console=ttySC1,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert, On 2026-01-06 12:40:12+0100, Geert Uytterhoeven wrote: > On Sun, 4 Jan 2026 at 23:14, Thomas Weißschuh <linux@weissschuh.net> wrote: (...) > > --- a/tools/testing/selftests/nolibc/Makefile.nolibc > > +++ b/tools/testing/selftests/nolibc/Makefile.nolibc > > @@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig > > DEFCONFIG_riscv64 = defconfig > > DEFCONFIG_s390x = defconfig > > DEFCONFIG_loongarch = defconfig > > -DEFCONFIG_sparc32 = sparc32_defconfig > > +DEFCONFIG_sparc32 = sparc64_defconfig > > How can we test sparc32 using a 64-bit kernel? CONFIG_COMPAT=y Please note that this changed in (the now committed) v2 anyways: https://lore.kernel.org/lkml/20260106-nolibc-sparc32-fix-v2-1-7c5cd6b175c2@weissschuh.net/ > > DEFCONFIG_sparc64 = sparc64_defconfig > > DEFCONFIG_m68k = virt_defconfig > > DEFCONFIG_sh4 = rts7751r2dplus_defconfig (...) Thomas
Hi Thomas,
On Tue, 6 Jan 2026 at 12:47, Thomas Weißschuh <linux@weissschuh.net> wrote:
> On 2026-01-06 12:40:12+0100, Geert Uytterhoeven wrote:
> > On Sun, 4 Jan 2026 at 23:14, Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> (...)
>
> > > --- a/tools/testing/selftests/nolibc/Makefile.nolibc
> > > +++ b/tools/testing/selftests/nolibc/Makefile.nolibc
> > > @@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig
> > > DEFCONFIG_riscv64 = defconfig
> > > DEFCONFIG_s390x = defconfig
> > > DEFCONFIG_loongarch = defconfig
> > > -DEFCONFIG_sparc32 = sparc32_defconfig
> > > +DEFCONFIG_sparc32 = sparc64_defconfig
> >
> > How can we test sparc32 using a 64-bit kernel?
>
> CONFIG_COMPAT=y
FWIW, testing 32-bit userland on a 64-bit kernel is something completely
different...
> Please note that this changed in (the now committed) v2 anyways:
> https://lore.kernel.org/lkml/20260106-nolibc-sparc32-fix-v2-1-7c5cd6b175c2@weissschuh.net/
Sorry, I hadn't noticed the newer version, as the latter does not
include some keywords to trigger my interest ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert, On 2026-01-06 14:36:23+0100, Geert Uytterhoeven wrote: > On Tue, 6 Jan 2026 at 12:47, Thomas Weißschuh <linux@weissschuh.net> wrote: > > On 2026-01-06 12:40:12+0100, Geert Uytterhoeven wrote: > > > On Sun, 4 Jan 2026 at 23:14, Thomas Weißschuh <linux@weissschuh.net> wrote: > > > > (...) > > > > > > --- a/tools/testing/selftests/nolibc/Makefile.nolibc > > > > +++ b/tools/testing/selftests/nolibc/Makefile.nolibc > > > > @@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig > > > > DEFCONFIG_riscv64 = defconfig > > > > DEFCONFIG_s390x = defconfig > > > > DEFCONFIG_loongarch = defconfig > > > > -DEFCONFIG_sparc32 = sparc32_defconfig > > > > +DEFCONFIG_sparc32 = sparc64_defconfig > > > > > > How can we test sparc32 using a 64-bit kernel? > > > > CONFIG_COMPAT=y > > FWIW, testing 32-bit userland on a 64-bit kernel is something completely > different... I can't really follow. We are testing the userspace nolibc here and assume that the kernel component already works correctly. Whether that is a native 32-bit kernel, 64-bit kernel with CONFIG_COMPAT=y or even qemu-user-sparc doesn't really matter in my opinion. What am I missing? > > Please note that this changed in (the now committed) v2 anyways: > > https://lore.kernel.org/lkml/20260106-nolibc-sparc32-fix-v2-1-7c5cd6b175c2@weissschuh.net/ > > Sorry, I hadn't noticed the newer version, as the latter does not > include some keywords to trigger my interest ;-) Now I am left wondering about the specific keyword that triggered on v1 but not v2 :-) Thomas
Hi Thomas,
On Tue, 6 Jan 2026 at 19:32, Thomas Weißschuh <linux@weissschuh.net> wrote:
> On 2026-01-06 14:36:23+0100, Geert Uytterhoeven wrote:
> > On Tue, 6 Jan 2026 at 12:47, Thomas Weißschuh <linux@weissschuh.net> wrote:
> > > On 2026-01-06 12:40:12+0100, Geert Uytterhoeven wrote:
> > > > On Sun, 4 Jan 2026 at 23:14, Thomas Weißschuh <linux@weissschuh.net> wrote:
> > >
> > > (...)
> > >
> > > > > --- a/tools/testing/selftests/nolibc/Makefile.nolibc
> > > > > +++ b/tools/testing/selftests/nolibc/Makefile.nolibc
> > > > > @@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig
> > > > > DEFCONFIG_riscv64 = defconfig
> > > > > DEFCONFIG_s390x = defconfig
> > > > > DEFCONFIG_loongarch = defconfig
> > > > > -DEFCONFIG_sparc32 = sparc32_defconfig
> > > > > +DEFCONFIG_sparc32 = sparc64_defconfig
> > > >
> > > > How can we test sparc32 using a 64-bit kernel?
> > >
> > > CONFIG_COMPAT=y
> >
> > FWIW, testing 32-bit userland on a 64-bit kernel is something completely
> > different...
>
> I can't really follow. We are testing the userspace nolibc here and
> assume that the kernel component already works correctly. Whether that
> is a native 32-bit kernel, 64-bit kernel with CONFIG_COMPAT=y or even
> qemu-user-sparc doesn't really matter in my opinion. What am I missing?
Oh sorry, I thought this was part of the actual nolibc implementation
used by the selftests, not a test for nolibc itself.
>
> > > Please note that this changed in (the now committed) v2 anyways:
> > > https://lore.kernel.org/lkml/20260106-nolibc-sparc32-fix-v2-1-7c5cd6b175c2@weissschuh.net/
> >
> > Sorry, I hadn't noticed the newer version, as the latter does not
> > include some keywords to trigger my interest ;-)
>
> Now I am left wondering about the specific keyword that triggered on v1
> but not v2 :-)
"m68k"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Thomas,
On Sun, Jan 04, 2026 at 11:14:13PM +0100, Thomas Weißschuh wrote:
> Since LLVM commit 39e30508a7f6 ("[Driver][Sparc] Default to -mcpu=v9 for
> 32-bit Linux/sparc64 (#109278)"), clang defaults to -mcpu=v9 for 32-bit
> SPARC builds. -mcpu=v9 generates instructions which are not recognized
> by qemu-sparc and qemu-system-sparc. Instead qemu-sparc32plus and
> qemu-system-sparc64 with a 64-bit kernel and CONFIG_COMPAT are needed.
>
> Rework the test setup so that -mcpu=v9 also works correctly.
Hmmm doesn't this mean that we're now unable to emit proper sparc32
instructions with this compiler ? I don't know which CPUs the kernel
still supports, but if it still supports these old SS-5, maybe we
should instead pass the correct -mcpu to clang so that it emits the
expected instructions, otherwise we're just hiding the regressing by
upgrading the test machine beyond what the kernel supports ? Of course
if they're no longer supported that's different, but I'm still seeing
traces of SparcStation5 in the code so I don't know what to think about
this.
Thanks,
Willy
On 2026-01-05 08:44:50+0100, Willy Tarreau wrote:
> Hi Thomas,
>
> On Sun, Jan 04, 2026 at 11:14:13PM +0100, Thomas Weißschuh wrote:
> > Since LLVM commit 39e30508a7f6 ("[Driver][Sparc] Default to -mcpu=v9 for
> > 32-bit Linux/sparc64 (#109278)"), clang defaults to -mcpu=v9 for 32-bit
> > SPARC builds. -mcpu=v9 generates instructions which are not recognized
> > by qemu-sparc and qemu-system-sparc. Instead qemu-sparc32plus and
> > qemu-system-sparc64 with a 64-bit kernel and CONFIG_COMPAT are needed.
> >
> > Rework the test setup so that -mcpu=v9 also works correctly.
>
> Hmmm doesn't this mean that we're now unable to emit proper sparc32
> instructions with this compiler ?
That depends on the definition of "proper" sparc32 :-)
Jokes aside, that compiler still supports -mcpu=v8 just fine,
only the default has changed.
> I don't know which CPUs the kernel
> still supports, but if it still supports these old SS-5, maybe we
> should instead pass the correct -mcpu to clang so that it emits the
> expected instructions, otherwise we're just hiding the regressing by
> upgrading the test machine beyond what the kernel supports ?
The 32-bit kernel also runs just fine on QEMU SS-5.
My reasoning was more that we now test both the v8 and v9 code paths in
nolibc. But in the end it doesn't really matter, as it is the same
kernel interface for v8 and v9. We can also just specify -mcpu=v8.
I'll do that for v2.
(...)
Thomas
On Mon, Jan 05, 2026 at 09:19:16AM +0100, Thomas Weißschuh wrote:
> On 2026-01-05 08:44:50+0100, Willy Tarreau wrote:
> > Hi Thomas,
> >
> > On Sun, Jan 04, 2026 at 11:14:13PM +0100, Thomas Weißschuh wrote:
> > > Since LLVM commit 39e30508a7f6 ("[Driver][Sparc] Default to -mcpu=v9 for
> > > 32-bit Linux/sparc64 (#109278)"), clang defaults to -mcpu=v9 for 32-bit
> > > SPARC builds. -mcpu=v9 generates instructions which are not recognized
> > > by qemu-sparc and qemu-system-sparc. Instead qemu-sparc32plus and
> > > qemu-system-sparc64 with a 64-bit kernel and CONFIG_COMPAT are needed.
> > >
> > > Rework the test setup so that -mcpu=v9 also works correctly.
> >
> > Hmmm doesn't this mean that we're now unable to emit proper sparc32
> > instructions with this compiler ?
>
> That depends on the definition of "proper" sparc32 :-)
For sure!
> Jokes aside, that compiler still supports -mcpu=v8 just fine,
> only the default has changed.
>
> > I don't know which CPUs the kernel
> > still supports, but if it still supports these old SS-5, maybe we
> > should instead pass the correct -mcpu to clang so that it emits the
> > expected instructions, otherwise we're just hiding the regressing by
> > upgrading the test machine beyond what the kernel supports ?
>
> The 32-bit kernel also runs just fine on QEMU SS-5.
OK!
> My reasoning was more that we now test both the v8 and v9 code paths in
> nolibc. But in the end it doesn't really matter, as it is the same
> kernel interface for v8 and v9. We can also just specify -mcpu=v8.
> I'll do that for v2.
OK thank you for checking and explaining!
Willy
© 2016 - 2026 Red Hat, Inc.