linux-kernel - Re: C aggregate passing (Rust kernel policy)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <F7E6DA3E-9B5C-4FDF-B7E7-0F1F02C5E74D@zytor.com>
Date: Thu, 20 Feb 2025 12:34:05 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Jan Engelhardt <ej@...i.de>
CC: 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>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
        ksummit@...ts.linux.dev
Subject: Re: C aggregate passing (Rust kernel policy)

On February 20, 2025 7:17:07 AM PST, Jan Engelhardt <ej@...i.de> wrote:
>
>On Thursday 2025-02-20 14:23, H. Peter Anvin wrote:
>>
>>People writing C seem to have a real aversion for using structures
>>as values (arguments, return values or assignments) even though that
>>has been valid since at least C90 and can genuinely produce better
>>code in some cases.
>
>The aversion stems from compilers producing "worse" ASM to this
>date, as in this case for example:
>
>```c
>#include <sys/stat.h>
>extern struct stat fff();
>struct stat __attribute__((noinline)) fff()
>{
>        struct stat sb = {};
>        stat(".", &sb);
>        return sb;
>}
>```
>
>Build as C++ and C and compare.
>
>$ g++-15 -std=c++23 -O2 -x c++ -c x.c && objdump -Mintel -d x.o
>$ gcc-15 -std=c23 -O2 -c x.c && objdump -Mintel -d x.o
>
>Returning aggregates in C++ is often implemented with a secret extra
>pointer argument passed to the function. The C backend does not
>perform that kind of transformation automatically. I surmise ABI reasons.

The ABI is exactly the same for C and C++ in that case (hidden pointer), so that would be a code quality bug. 

But I expect that that is a classic case of "no one is using it, so no one is optimizing it, so no one is using it." ... and so it has been stuck for 35 years. 

But as Linus pointed out, even the C backend does quite well if the aggregate fits in two registers; pretty much every ABI I have seen pass two-machine-word return values in registers (even the ones that pass arguments on the stack.)