Re: [PATCH] tools/nolibc: Add support for SPARC

[Willy Tarreau <w@1wt.eu>]

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