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

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

On Mon, Mar 17, 2025 at 06:52:57PM +0100, Thomas Weißschuh wrote:
> On 2025-03-17 08:37:46+0100, Willy Tarreau wrote:
> > 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).
> 
> An old kernel should be perfectly fine, no?

I don't think so (it depends how old in fact), keep in mind that
we've removed support for a number of legacy syscalls.

> > > +/* 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.
> 
> 128 is the context window and 2047 is the stack bias.
> I'll try to make it clearer.

OK thanks, but that remains quite strange to me. How can we end up
here with such an unaligned stack ? At the very minimum I'd expect
all offsets to be multiple of 8.

> > 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.
> 
> There is a graphic in the psABI [0] under "Process Stack and Registers".

Thanks for the link! Are you sure you can get rid of the window save
area ? I'm seeing that apparently it's used with save / restore, which
*if I remember well (30 years ago)* were used along with register bank
switches. In 3-12 it's written:

  Some registers have assigned roles.
    %sp or %o6 The stack pointer holds the limit of the current stack frame,
    %which is the address of the stacks bottommost, valid word. Stack contents
    %below the stack pointer are undened. At all times the stack pointer must
    %point to a doubleword aligned, 16- word window save area.

> I'll write something based on that.

Thanks!

> > > +		"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).
> 
> Yeah, it brings memories to the work on MIPS support.

absolutely!

Thanks,
Willy