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
