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