Re: [PATCH v2] tools/nolibc: add support for Alpha
Thomas Weißschuh <[email protected]> Sun, 2 Aug 2026 09:35:33 +0200
| Newsgroups | gmane.linux.kernel,gmane.linux.ports.alpha |
|---|---|
| Message-ID | <[email protected]> |
On 2026-08-02 09:06:59+0200, Magnus Lindholm wrote: > On Wed, Jul 22, 2026 at 3:28 AM Thomas Weißschuh <[email protected]> wrote: > > > + * Syscalls for Alpha: > > + * - registers are 64-bit > > + * - syscall number is passed in $0/v0 > > + * - the system call is performed by calling callsys > > + * - syscall return comes in $0/v0, error flag in $19/a4 > > typo in comment ? should be: > syscall return comes in $0/v0, error flag in $19/a3 Ack. > > + * - arguments are passed in $16/a0 to $21/a5 > > + * - GCC does not support symbol register names > > + */ > > > +#define __nolibc_syscall5(num, arg1, arg2, arg3, arg4, arg5) \ > > +({ \ > > + register long _num __asm__ ("$0") = (num); \ > > + register long _err __asm__ ("$19"); \ > > + register long _arg1 __asm__ ("$16") = (long)(arg1); \ > > + register long _arg2 __asm__ ("$17") = (long)(arg2); \ > > + register long _arg3 __asm__ ("$18") = (long)(arg3); \ > > + register long _arg4 __asm__ ("$19") = (long)(arg4); \ > > + register long _arg5 __asm__ ("$20") = (long)(arg5); \ > > + \ > > + __asm__ volatile ( \ > > + "callsys" \ > > + : "+r"(_num), "=r"(_err) \ > > + : "r"(_arg1), "r"(_arg2), "r"(_arg3), "r"(_arg4), "r"(_arg5) \ > > + : _NOLIBC_SYSCALL_CLOBBERLIST, "$21" \ > > + ); \ > > + _err ? -_num : _num; \ > > +}) > > One observation, although I am not an expert on GCC inline-assembly constraints: > in the four- through six-argument wrappers, $19/a3 contains the fourth > argument on > entry and the error indicator on return. Would using a single read/write operand > for $19, similar to the handling of $0, make that transition clearer? Good catch. We had miscompilations from clang in this case before. So I'll fix this up to be on the safe side. > Michael’s successful testing on both XP1000 and ES45 also shows that the current > implementation works correctly on real hardware, so I do not consider > changing the > operand representation a requirement for v3. From my side, addressing the $19/a4 > comment typo, together with the "TASK_SIZEi" typo already noted by Willy, > would be sufficient. > > Michael’s testing should be sufficient, but I also have access to Alpha hardware > and would be happy to assist with any additional testing if useful. Thanks for the offer. For me Michael's Tested-by would be sufficient. Thomas