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

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

On 2026-07-27 05:30:43+0200, Willy Tarreau wrote:
> On Sun, Jul 26, 2026 at 10:16:42PM +0200, Thomas Weißschuh wrote:
> > 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.
> 
> Well, at other places we already have typeof(arg) which is exactly the
> same, more explicit, and doesn't come with such restrictions, so I'd
> rather suggest we use it instead.

Agreed.

> > We really should have a documented policy for that.
> 
> We could indeed. Till now the principle has been not to break support for
> older compilers without a really good reason (i.e. something that would
> become too complicated or impossible to do). At least we should add a
> README in the directory indicating what is oldest supported version, as
> it really doesn't cost anything to preserve support for that for a long
> time.

Also agreed. I don't want to intentionally break older compilers.
But if we know where the baseline is today we don't have to have
discussions about changes which would *not* violate said baseline
anyways.

Also as mentioned by you before, we should not tie ourselves to the
general kernel baseline. nolibc is much simpler and doesn't have
the same requirements.

> > > +	__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.
> 
> Yes, I wasn't aware of that either. Also I'd like to recheck that
> MIPS continues to work fine because I seem to remember that its
> constraints tend to be harder to respect in syscall6() and it took
> us a few times to get it right. But maybe this could have helped
> instead.

Ack.


Thomas