On Sun, Mar 16, 2025 at 02:55:02PM +0100, Thomas Weißschuh wrote:
Add support for 32bit and 64bit SPARC to nolibc.
Oh nice!
Signed-off-by: Thomas Weißschuh linux@weissschuh.net
This is only tested on QEMU. Any tests on real hardware would be very welcome.
I still have a working U60 here, but under solaris. Such machines are not trivial to boot on alternate OSes (and when you find a working image usually it's based on an old kernel). But I've run it under Linux 20 years ago, so I know it was supported. I may give it a try when I find a moment, but let's not wait for this!
A few comments below:
diff --git a/tools/include/nolibc/arch-sparc.h b/tools/include/nolibc/arch-sparc.h new file mode 100644 index 0000000000000000000000000000000000000000..cb5543eca87bb4d52cfba4c0668e35cbbf6dd124 --- /dev/null +++ b/tools/include/nolibc/arch-sparc.h @@ -0,0 +1,191 @@ +/* SPDX-License-Identifier: LGPL-2.1 OR MIT */ +/*
- SPARC (32bit and 64bit) specific definitions for NOLIBC
- Copyright (C) 2025 Thomas Weißschuh linux@weissschuh.net
- */
+#ifndef _NOLIBC_ARCH_SPARC_H +#define _NOLIBC_ARCH_SPARC_H
+#include <linux/unistd.h>
+#include "compiler.h" +#include "crt.h"
+/*
- Syscalls for SPARC:
- registers are native word size
- syscall number is passed in g1
- arguments are in o0-o5
- the system call is performed by calling a trap instruction
- syscall return value is in 0a
^^ What is "0a" here ? I suspect a typo and you meant "o0".
+/* startup code */ +void __attribute__((weak, noreturn)) __nolibc_entrypoint __no_stack_protector _start(void) +{
- __asm__ volatile (
/** Save stack pointer to o0, as arg1 of _start_c.* Account for window save area and stack bias.*/+#ifdef __arch64__
"add %sp, 128 + 2047, %o0\n"
It's really unclear where this magical 2047 comes from, I think it must be explained in the comment above so that someone disagreeing with it later can figure whether it's right or wrong.
+#else
"add %sp, 64, %o0\n"+#endif
Also, I could be wrong, but from my old memories of playing with the stack on SPARC long ago, I seem to remember that the stack is growing down. Thus I find these "add" suspicious or at least confusing. You mention "window save area and stack bias" above, I'm not sure what it refers to, but if we can safely erase parts of the stack because too much was preserved, maybe some more explanation about the initial and target layouts is deserved here.
"b,a _start_c\n" /* transfer to c runtime */
OK great, the delayed slot is covered! (that type of thing can work by pure luck in one test and fail in another one depending on what bytes follow the jump).
Thanks!
Acked-by: Willy Tarreau w@1wt.eu
Willy