Message-ID: <4c9573ba-b939-4ac7-a163-9e8bd7052fe5@embecosm.com>
Date: Tue, 25 Feb 2025 18:30:01 +0100
From: Arthur Cohen <arthur.cohen@...ecosm.com>
To: Ventura Jack <venturajack85@...il.com>,
 Philip Herron <herron.philip@...glemail.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Theodore Ts'o <tytso@....edu>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Kent Overstreet
 <kent.overstreet@...ux.dev>, Gary Guo <gary@...yguo.net>, airlied@...il.com,
 boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de,
 gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com,
 ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, Ralf Jung <post@...fj.de>,
 Antoni Boucher <bouanto@...o.com>
Subject: Re: C aggregate passing (Rust kernel policy)

Hi!

On 2/25/25 4:55 PM, Ventura Jack wrote:
> On Mon, Feb 24, 2025 at 9:42 AM Philip Herron
> <herron.philip@...glemail.com> wrote:
>> My 50 cents here is that gccrs is trying to follow rustc as a guide, and
>> there are a lot of assumptions in libcore about the compiler, such as lang
>> items, that we need to follow in order to compile Rust code. [Omitted]
>>
>> Thanks
>>
>> --Phil
> 
> Is this snippet from the Rust standard library an example of one
> of the assumptions about the compiler that the Rust standard library
> makes? The code explicitly assumes that LLVM is the backend of
> the compiler.
> 
> https://github.com/rust-lang/rust/blob/master/library/core/src/ffi/va_list.rs#L292-L301
> 
>          // FIXME: this should call `va_end`, but there's no clean way to
>          // guarantee that `drop` always gets inlined into its caller,
>          // so the `va_end` would get directly called from the same function as
>          // the corresponding `va_copy`. `man va_end` states that C
> requires this,
>          // and LLVM basically follows the C semantics, so we need to make sure
>          // that `va_end` is always called from the same function as `va_copy`.
>          // For more details, see https://github.com/rust-lang/rust/pull/59625
>          // and https://llvm.org/docs/LangRef.html#llvm-va-end-intrinsic.
>          //
>          // This works for now, since `va_end` is a no-op on all
> current LLVM targets.
> 
> How do you approach, or plan to approach, code like the above in gccrs?
> Maybe make a fork of the Rust standard library that only replaces the
> LLVM-dependent parts of the code? I do not know how widespread
> LLVM-dependent code is in the Rust standard library, nor how
> well-documented the dependence on LLVM typically is. In the above
> case, it is well-documented.
> 
> Best, VJ.

Things like that can be special-cased somewhat easily without 
necessarily forking the Rust standard library, which would make a lot of 
things a lot more difficult for us and would also not align with our 
objectives of not creating a rift in the Rust ecosystem.

The `VaListImpl` is a lang item in recent Rust versions as well as the 
one we currently target, which means it is a special type that the 
compiler has to know about, and that we can easily access its methods or 
trait implementation and add special consideration for instances of this 
type directly from the frontend. If we need to add a call to `va_end` 
anytime one of these is created, then we'll do so.

We will take special care to ensure that the code produced by gccrs 
matches the behavior of the code produced by rustc. To us, having the 
same behavior as rustc does not just mean behaving the same way when 
compiling code but also creating executables and libraries that behave 
the same way. We have already started multiple efforts towards comparing 
the behavior of rustc and gccrs and plan to continue working on this in 
the future to ensure maximum compatibility.

Kindly,

Arthur

Powered by blists - more mailing lists