Re: [PATCH 1/4] tools/nolibc: evaluate syscall() arguments before the arch macros

["Thomas Weißschuh" <linux@weissschuh.net>]

Thanks!

On 2026-07-26 17:13:02+0700, Ammar Faizi wrote:
(...)

> +#define __nolibc_syscall_eval6(_n, _a1, _a2, _a3, _a4, _a5, _a6)	\
> +({									\
> +	__auto_type __sc_n = (_n);					\
> +	__auto_type __sc_a1 = (_a1);					\
> +	__auto_type __sc_a2 = (_a2);					\
> +	__auto_type __sc_a3 = (_a3);					\
> +	__auto_type __sc_a4 = (_a4);					\
> +	__auto_type __sc_a5 = (_a5);					\
> +	__auto_type __sc_a6 = (_a6);					\

__auto_type is only supported from GCC 4.9. I think this is old enough,
but it should be mentioned at least.
We really should have a documented policy for that.

> +	__nolibc_syscall6(__sc_n, __sc_a1, __sc_a2, __sc_a3, __sc_a4,	\
> +			  __sc_a5, __sc_a6);				\
> +})
> +
>  #define ___nolibc_syscall_narg(_0, _1, _2, _3, _4, _5, _6, N, ...) N
>  #define __nolibc_syscall_narg(...) ___nolibc_syscall_narg(__VA_ARGS__, 6, 5, 4, 3, 2, 1, 0)
> -#define __nolibc_syscall(N, ...) __nolibc_syscall##N(__VA_ARGS__)
> +#define __nolibc_syscall(N, ...) __nolibc_syscall_eval##N(__VA_ARGS__)

I'd like to apply the same thing to the __nolibc_syscallN()
usage within nolibc itself. While today we seem not to have any
problematic cases, at least I was not aware of the issue and breakage
might creep in accidentally. We can problably rename the
architecture-specific macros to __nolibc_syscall_archN()
and make __nolibc_syscall() the properly evaluating wrapper.

>  #define __nolibc_syscall_n(N, ...) __nolibc_syscall(N, __VA_ARGS__)
>  #define _syscall(...) __nolibc_syscall_n(__nolibc_syscall_narg(__VA_ARGS__), ##__VA_ARGS__)
>  #define syscall(...) __sysret(_syscall(__VA_ARGS__))


Thomas