From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEDD513777E for ; Sun, 19 Apr 2026 21:35:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776634513; cv=none; b=DwkHRNOI1uS2F6P91HeCgoSPRVtdBt7sNqXwaiXMpLATg0Q4ev0DiIS6duCahsmSrbp9ciA85+CUcSGhD/Jj+ne9wQa+kr16NrXvkvINpvWUthngFqqbL3GKikp41q98CN4E446Y4UT1ZglonW0Pf7yp4nIpXjBHnevzRQ8QRi4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776634513; c=relaxed/simple; bh=Fse/yXFyt3f5jXfJBwECbIS8BxNShBa6LygztfSNmtk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fBAuKrPmFaZoJWM9/wGE+T5E/Non9vxjFCtKiiGUnE9TpBR/lWbHh6b6ZWahW4l4Onidq/USnOxaHiViXt6WQ4Iei0Etj/esoN2OIg9Y0ozNU3H5pCdy8UKF2Thye8BtYA3eYDK6dRfzz/QobwhgKxDM+l3vJxnd9IOlPsLaGw0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=H/7TM4xR; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H/7TM4xR" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-43cf7683a28so1541277f8f.2 for ; Sun, 19 Apr 2026 14:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776634510; x=1777239310; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=vIKxfclA+1VP7Js6u7k5/DVqZ0z605YWmOPJooDaYMg=; b=H/7TM4xRrmT9VISpvHzI8RvtIxXect2Ms0VLbAP941fXsGlqm/0HpN28OywTGeOpbr UF0ORvSUaehG9sFPnIalVe1ky0mrDGWF26VfLVWaydkL78ao1Z3J/AD/Rw0I9baXugmp qm4K/CNGidIlgZlxVjQpTHqFeVn/UYwqvUqQaAGcL1k4Yhx0ADf+li/2qr82VOvREzB6 2Br3jdJby9S9b5ERm47ZQ4pAaA3zIbaVKDju3YDQgtMmCtnhcf6fb4TgMUoOInuSqOGP f2oT30g6jfN8T43FNfWoc71G6zhi7u69Crmu3g275QeFuYpaf4ckZAHUohHzgUT9J/my zIvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776634510; x=1777239310; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vIKxfclA+1VP7Js6u7k5/DVqZ0z605YWmOPJooDaYMg=; b=IYrRiA0ushcKneVz11jFQrsChGQYjC8yqvE4TY7p3EjWT6t9++MTgGATe+06q8VFoF cugtXUQ6PzJfkt+JRzIftJtxKkK97YiSjfz0f1sux5vky3EPEg3FmTL5WCMtuYbZPz7M bfYtGRTm9T2S7mGr4Yhlg+xfanN+srR8nPS678K+4WueAKLbEuvrWFR5yJiAqevy+TGZ ol7oPzVFA0M+mE6QbyQNYm4LXav0AyoqIUZHK2IZfbyZwvNiGD5rDBpjvqLCLD298lNX aOl6l6AVmtZOiEwCkUggba2erfx5UK3Zy8oqIsJ2kfi9JmpGAUfRr16Er7r9u4g3E8Ps cwRw== X-Forwarded-Encrypted: i=1; AFNElJ8hxcqdBeDkDsO/IZPxGWuxKxeq0VblJ8nIM6D+sER3L2B+EA3iuxLSTOD755wbcCAabsYH6nMQqyjxeXQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2aPVi6NZf9SNxs+svPcii7alu5ohjP1HgJECa/1NyyMh4hTxa XMxBOm9aWpEGoyDN+3BEC2+mJXYFJqt8+koAZ2TY7KaFuvvV/oA23eXZTk3ChFW4 X-Gm-Gg: AeBDieuECVZ25KKIZ16vLrWaXMW5hYY64lyc4eyKJRfVEo5puppKmECqtp2ntnxtXMj 8GXCVAIflWZ0eoSRcKo3hg8y0icDYncm5e68/ut+5EYk0iBfVTTT0uxNM+WWqsMRRhCVR02U3Ua ENO3E9IqlDKBBuktG1SJ7RLS8To2db+LHeYIvQ96/6BDQkajx7SWzUPoMUvltDJNnNrEYQCQEsg zDC3dcLT19fk6CHpqgnTiOG76+aRXX6edOIr99dg4ZWwFHu4ZyUaZ2A1AL+4RPaJFNr8mrc+3oK 0bZKPGfwPVEVGf1KH4WNb3TqqYDiulLjfjgOiiMeAXbp5Fg5yeZGXEENMAmdA0YyjRsi8ZZVTgC aFbAbvuCnwp6YZuQ8ouZ8JAmFvRinpUVXub9jfJDuX6OD+x9DltgoGMKOeEdvC/UK/u2uWnnsI4 1abHVOhc2vlzrntWg4KmnbrdTBJzosQVXohn3FnE+mp5XLsNB/f6TREaiqHTX6yqc2p72DTpox5 tw= X-Received: by 2002:a05:6000:2502:b0:43e:b0f8:c564 with SMTP id ffacd0b85a97d-43fe3dbd756mr16154591f8f.9.1776634509794; Sun, 19 Apr 2026 14:35:09 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4cc2cacsm23668880f8f.13.2026.04.19.14.35.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2026 14:35:09 -0700 (PDT) Date: Sun, 19 Apr 2026 22:35:07 +0100 From: David Laight To: Willy Tarreau Cc: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , 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: <20260419223507.1dc5554a@pumpkin> In-Reply-To: References: <20260418-nolibc-largefile-v1-0-b91f0775bac3@weissschuh.net> <20260418-nolibc-largefile-v1-5-b91f0775bac3@weissschuh.net> <20260418121442.6ca95de1@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 19 Apr 2026 17:30:13 +0200 Willy Tarreau wrote: > On Sat, Apr 18, 2026 at 01:54:55PM +0200, Thomas Wei=C3=9Fschuh wrote: > > Hey David, > >=20 > > Apr 18, 2026 13:14:46 David Laight : > > =20 > > > On Sat, 18 Apr 2026 12:20:00 +0200 > > > Thomas Wei=C3=9Fschuh wrote: > > > =20 > > >> 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 whi= ch > > >> 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=C3=9Fschuh > > >> --- > > >> 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 numb= ers instead. */ > > >> @@ -66,12 +68,14 @@ > > >> #define _NOLIBC_SYSCALL_STACK_RESERVE > > >> #define _NOLIBC_SYSCALL_STACK_UNRESERVE > > >> > > >> +#define _NOLIBC_SYSCALL_REG register long long > > >> + > > >> #endif /* _ABIO32 */ =20 > > > > > > 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. =20 > >=20 > > 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. =20 >=20 > 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. Fair enough, there probably aren't enough examples to make it worth while. I would suggest using "+r" for the in-out registers; and [arg5] for the ones that get pushed, reliably counting to 7 is hard :-) Related to one of the other patches, I can't imagine how N32 getting a 64bit value truncated would be a qemu bug. Just seems wrong - isn't the cpu just running in 64bit mode ? But I've not tried to look. I've never used mips - never mind mips64, so I'm not doing to spot anything subtle. (I have used (and written - yes in VHDL [1]) the nios2; which is sort of the same until you look closely.) [1] Altera/Intel deprecated the nios2 (saying you could use riscv instead), but it has slightly different instructions and they didn't publish the actual supported instructions or timings. Since some of 'our' code was clock-count critical I just re-implemented the 'integer unit' (no mmu, no fp, no cache (or rather code+data only from 'cache' with no backing memory), no interrupts). Took a few weeks and I'm no vhdl expert. David >=20 > Willy