[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260416140241.GF1827@brightrain.aerifal.cx>
Date: Thu, 16 Apr 2026 10:02:41 -0400
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] mipsn32: pass syscall arguments as long long
instead of long
On Thu, Apr 16, 2026 at 10:00:31AM -0400, Rich Felker wrote:
> On Thu, Apr 16, 2026 at 03:43:38PM +0200, Alex Rønne Petersen wrote:
> > On Thu, Apr 16, 2026, at 15:13, Rich Felker wrote:
> > > On Thu, Apr 16, 2026 at 04:10:17AM +0200, Alex Rønne Petersen wrote:
> > >> This matches what is done for the x32 port. As far as I can tell based on kernel
> > >> and glibc sources, this is the expected kABI for mipsn32. Before this patch, you
> > >> would get compiler warnings about truncation of off_t values in various syscall
> > >> wrappers.
> > >
> > > This patch doesn't actually do what the description says. The
> > > arguments passed in to the __syscallN inlines are long long, but the
> > > register locals passed into the inline asm are still long.
> >
> > Ugh, thanks for pointing that out. I was tunnel-visioning a bit and totally missed that. Will send a v2 if we can agree that the change is correct...
> >
> > > I'm skeptical that the intendedchange is correct to begin with tho. As
> > > I understand it, x32 actually has the kernel receive 64-bit registers
> > > and might even use 64-bit values in a few places, but mips n32 always
> > > treats the syscall args as 32-bit.
> >
> > I honestly can't find any evidence that n32 uses 32-bit syscall arguments. I'd be surprised if it did, since a MIPS32_N32 kernel is always 64BIT (in Kconfig terms), and the n32 calling convention uses the full 64-bit registers, so if anything it'd take considerable extra effort for the n32 syscall path to use 32-bit arguments (when you consider e.g. off_t value splitting into separate registers), and I just don't see that anywhere in the kernel code. glibc also explicitly makes __syscall_arg_t 64-bit on n32, just as on x32.
> >
> > > If off_t is being truncated somewhere, this is probably actually a
> > > bug, and the patch is just burying it, not fixing it. Can you report
> > > that so it can be investigated?
> >
> > It's truncated in basically any syscall involving off_t because of
> > the definitions of __SYSCALL_LL_E() and __SYSCALL_LL_O() in the
> > mipsn32 port. For the x32 port, it's not a problem because syscall
> > arguments are passed as 64-bit.
>
> Oh lovely. So we need to figure out if that's how the kernel actually
> expects it. If so, your patch is right. But if not, those macro
> definitions are wrong.
>
> I believe there was some concern over mipsn32 lseek at some point
> return value in the past that was casually raised but never
> resolved...
OK, it was addressed, in commit
918c5fa0fc656e49b1ab9ce47183a23e3a36bc00
This sheds some light on the situation. At least lseek does take a
64-bit argument. So if this is how it works elsewhere then your patch
is probably right.
AFAIK lseek is still the only place with an off_t return value, so we
can probably leave the return type as long.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
