Hi Benjamin, On Fri, Sep 19, 2025 at 05:34:16PM +0200, Benjamin Berg wrote: > From: Benjamin Berg <[email protected]> > > Add NOLIBC_CFLAGS and NOLIBC_OBJS to build files against nolibc rather > than libc. With this it is possible to move to nolibc in smaller steps. > > Set NOLIBC_IGNORE_ERRNO, as the nolibc errno implementation is overly > simple and cannot handle threading. nolibc provides sys_* functions that > do not emulate the libc errno behaviour and can be used instead.
Just for my understanding, in case we can improve portability, why is it needed to disable errno processing here ? Even if it's limited, it shouldn't cause trouble. I mean that if a program works with it defined, logically it should also work without since the only difference is that the errno global variable will not be defined nor assigned on syscall returns. > Guard the syscall definition as it is a macro in nolibc. This one is interesting: --- a/arch/um/include/shared/os.h +++ b/arch/um/include/shared/os.h @@ -327,7 +327,9 @@ extern int __ignore_sigio_fd(int fd); /* tty.c */ extern int get_pty(void); +#ifndef NOLIBC long syscall(long number, ...); +#endif In nolibc, the syscall() definition indeed looks like this now: #define __syscall_narg(_0, _1, _2, _3, _4, _5, _6, N, ...) N #define _syscall_narg(...) __syscall_narg(__VA_ARGS__, 6, 5, 4, 3, 2, 1, 0) #define _syscall(N, ...) __sysret(my_syscall##N(__VA_ARGS__)) #define _syscall_n(N, ...) _syscall(N, __VA_ARGS__) #define syscall(...) _syscall_n(_syscall_narg(__VA_ARGS__), ##__VA_ARGS__) Except by mapping all syscalls to _syscall(6, ...) and always passing 6 args, I'm not seeing any easy way to dynamically adapt to the number of arguments if we wanted to move it to a function. Also, a static function would still conflict with the definition above. I'm wondering about what extent the documented "long syscall(number, ...)" is valid in fact, as I doubt it's really implemented anywhere as a generic function taking the maximum amount of args. Thus I think that the guard is indeed the only option to reconciliate these two incompatible approaches. By the way I think it could be more future- proof to do the guard on the syscall macro definition itself (which would thus also resist it being passed by "-Dsyscall(x)=(...)" or any other form: +#ifndef syscall long syscall(long number, ...); +#endif Regards, Willy
