From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 202DA1A6807 for ; Sun, 19 Apr 2026 15:30:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776612620; cv=none; b=VM+AMAL6BN9jSpgXbefxxY2+bAo07tpLfDjoakMdxIvF/6nHc4K/0S+R1pzJqwdZDM83Y43xvf2YxdULMCpvvYYMr53qh07CPgeSopPK+MFFTk9T/pP71F7rsaKjj11n8GMN9gziaEPHf+YidFk2gwPXQWCtqXHdZP1+ktVJXwE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776612620; c=relaxed/simple; bh=9Nsx0RAuE5lU98WC2ykq/3yNT6R5qxXAQWfQWZ3ZNEw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c5oVJx5hNpB75TG3ULpphI2S27CzyzweKJedpNxj42Ev4vi5Fihjxt86+gGZAS+qyTdcSWjYN4KxHBDVgH5FGFky3RV7a5d+1HvcjjOsjypANtCX16Xs8CsXLiR8v1bbYWJJWVpq91iCYPPKv5lwDZQ6JLV/8Q7sC4xAI+SVdeQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=fWX+eD1W; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="fWX+eD1W" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1776612616; bh=dVk8Rf4S06q4GNca3BJTHRqA0+Uz9VRjdNf2kFaOumQ=; h=From:Message-ID:From; b=fWX+eD1WnDr/+b0Qf6UQ1zdGcirdJeNX2D6nrpVlMgAd2ChezN69o1cxSnBExZK/e mZXMGKY+gYNLj/9UQSjyy+Pl3errin9Ir3c+IZQ2mkKe4lmfqNoXfuk02o/ORM/4Xy RWMrnLpTTgs3ovkwc4O+45QAzWNy4e+fd0v6CVeI= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id F1925C09A5; Sun, 19 Apr 2026 17:30:15 +0200 (CEST) Date: Sun, 19 Apr 2026 17:30:13 +0200 From: Willy Tarreau To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: David Laight , Daniel Palmer , linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/7] tools/nolibc: handle 64-bit system call arguments on MIPS N32 Message-ID: References: <20260418-nolibc-largefile-v1-0-b91f0775bac3@weissschuh.net> <20260418-nolibc-largefile-v1-5-b91f0775bac3@weissschuh.net> <20260418121442.6ca95de1@pumpkin> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, Apr 18, 2026 at 01:54:55PM +0200, Thomas Weißschuh wrote: > Hey David, > > Apr 18, 2026 13:14:46 David Laight : > > > On Sat, 18 Apr 2026 12:20:00 +0200 > > Thomas Weißschuh wrote: > > > >> The N32 system call ABI expects 64-bit values directly in registers. > >> This does not work on nolibc currently, as a 'long' is only 32 bits > >> wide. Switch the system call wrappers to use 'long long' instead which > >> can handle 64-bit values on N32. As on N64 'long' and 'long long' are > >> the same, this does not change the behavior there. > >> > >> Signed-off-by: Thomas Weißschuh > >> --- > >> tools/include/nolibc/arch-mips.h | 94 +++++++++++++++++++++------------------- > >> 1 file changed, 49 insertions(+), 45 deletions(-) > >> > >> diff --git a/tools/include/nolibc/arch-mips.h b/tools/include/nolibc/arch-mips.h > >> index bb9d580ea1b1..557ef34d9df8 100644 > >> --- a/tools/include/nolibc/arch-mips.h > >> +++ b/tools/include/nolibc/arch-mips.h > >> @@ -55,6 +55,8 @@ > >> #define _NOLIBC_SYSCALL_STACK_RESERVE "addiu $sp, $sp, -32\n" > >> #define _NOLIBC_SYSCALL_STACK_UNRESERVE "addiu $sp, $sp, 32\n" > >> > >> +#define _NOLIBC_SYSCALL_REG register long > >> + > >> #else /* _ABIN32 || _ABI64 */ > >> > >> /* binutils, GCC and clang disagree about register aliases, use numbers instead. */ > >> @@ -66,12 +68,14 @@ > >> #define _NOLIBC_SYSCALL_STACK_RESERVE > >> #define _NOLIBC_SYSCALL_STACK_UNRESERVE > >> > >> +#define _NOLIBC_SYSCALL_REG register long long > >> + > >> #endif /* _ABIO32 */ > > > > Since you need to use a #define, did you think about: > > #define _NOLIBC_SYSCALL_REG(var, reg) register long long var __asm__ (reg) > > to shorten the lines and the repetitive pattern. > > I didn't think of this. > Personally I am fine with both variants. > The parameterized macro is a bit weird > is it breaks the normal syntax. > Let's wait what Willy thinks. I don't have a strong preference either, however macros make debugging particularly painful and are only interesting when they save lots of complicated code, which is not the case here. So I'd say that Thomas' approach is minimalistic and obfuscates the least. If these were to be exposed to end users, I think David's proposals would be better, but since it's only for internal consumption and changed only once every 5 years, maybe better keep the explicit definitions like in Thomas' approach. Willy