[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ACFAF4FA-755C-4AD8-9826-168E4A7337B9@gmail.com>
Date: Fri, 21 Feb 2025 12:07:17 -0800
From: comex <comexk@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Laight <david.laight.linux@...il.com>,
Jan Engelhardt <ej@...i.de>,
"H. Peter Anvin" <hpa@...or.com>,
Greg KH <gregkh@...uxfoundation.org>,
Boqun Feng <boqun.feng@...il.com>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Christoph Hellwig <hch@...radead.org>,
rust-for-linux <rust-for-linux@...r.kernel.org>,
David Airlie <airlied@...il.com>,
linux-kernel@...r.kernel.org,
ksummit@...ts.linux.dev
Subject: Re: C aggregate passing (Rust kernel policy)
> On Feb 21, 2025, at 11:12 AM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> On Fri, 21 Feb 2025 at 10:34, David Laight <david.laight.linux@...il.com> wrote:
>>
>> As Linus said, most modern ABI pass short structures in one or two registers
>> (or stack slots).
>> But aggregate returns are always done by passing a hidden pointer argument.
>>
>> It is annoying that double-sized integers (u64 on 32bit and u128 on 64bit)
>> are returned in a register pair - but similar sized structures have to be
>> returned by value.
>
> No, they really don't. At least not on x86 and arm64 with our ABI.
> Two-register structures get returned in registers too.
This does happen on older ABIs though.
With default compiler flags, two-register structures get returned on the stack on 32-bit x86, 32-bit ARM, 32-bit MIPS, both 32- and 64-bit POWER (but not power64le), and 32-bit SPARC. On most of those, double-register-sized integers still get returned in registers.
I tested this with GCC and Clang on Compiler Explorer:
https://godbolt.org/z/xe43Wdo5h
Again, that’s with default compiler flags. On 32-bit x86, Linux passes -freg-struct-return which avoids this problem. But I don’t know whether or not there’s anything similar on other architectures. This could be easily answered by checking actual kernel binaries, but I didn’t :)
Powered by blists - more mailing lists