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,
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
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
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@w...
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@w...
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
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@w...
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@w...
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
linux-kselftest-mirror@lists.linaro.org
-
Geert Uytterhoeven -
Thomas Weißschuh -
Willy Tarreau