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@xxxxxxxxxxxxxx>
> > > ---
> > > 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
