All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: "Antoni Boucher" <bouanto@zoho.com>,
	"Emilio Cobos Álvarez" <emilio@crisal.io>,
	"Arthur Cohen" <arthur.cohen@embecosm.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Josh Triplett" <josh@joshtriplett.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Will Deacon" <will@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
	"Bill Wendling" <morbo@google.com>,
	"Justin Stitt" <justinstitt@google.com>,
	"Nicolas Schier" <nicolas.schier@linux.dev>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Uladzislau Rezki" <urezki@gmail.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev, linux-kbuild@vger.kernel.org,
	linux-mm@kvack.org, nouveau@lists.freedesktop.org,
	"Matthew Maurer" <mmaurer@google.com>
Subject: Re: [PATCH 4/4] build: rust: provide an option to inline C helpers into Rust
Date: Thu, 4 Dec 2025 13:39:06 +0100	[thread overview]
Message-ID: <20251204123906.GL2528459@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CANiq72=r+Fmu0uuNF=6x36GWWQZGZk9gApnMZxakJavviwG+ug@mail.gmail.com>

On Thu, Dec 04, 2025 at 12:57:31PM +0100, Miguel Ojeda wrote:
> On Thu, Dec 4, 2025 at 12:11 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Right. Earlier I also proposed using libclang to parse the C header and
> > inject that. This might be a little simpler, in that..
> 
> Yeah, that would be closer to the `bindgen` route in that `libclang`
> gets already involved.
> 
> > ... if you build rustc against libclang they are necessarily from the
> > same LLVM build.
> 
> So currently there are 3 "LLVMs" that get involved:
> 
>   - The one Clang uses (in LLVM=1 builds).

Well, being on Debian, I'm more likely to be using LLVM=-22 (or whatever
actual version is required, 22 just being the latest shipped by Debian
at this point in time).

>   - The one `rustc` uses (the LLVM backend).
>   - The one `bindgen` uses (via libclang).

These are not necessarily the same? That is, is not bindgen part of the
rustc project and so would be built against the same LLVM?

> If that is all done within `rustc` (so no `bindgen`), then there may
> still be `rustc` vs. Clang mismatches, which are harder to resolve in
> the Rust side at least (it is easier to pick another Clang version to
> match).
> 
> For those using builds from distros, that shouldn't be a problem.
> Others using external `rustc` builds, e.g. from `rustup` (e.g. for
> testing different Rust versions) it would be harder.

Make rust part of LLVM and get them all built and distributed
together... such that LLVM=-23 will get me a coherent set of tools.

/me runs like crazeh ;-)

> There is also the question about GCC. A deeper integration into
> `rustc` would ideally need to have a way (perhaps depending on the
> backend picked?) to support GCC builds properly (to read the header
> and flags as expected, as you mention).

Right, so the backend that spits out C could obviously just pass through
any C headers. But otherwise, inlining C headers (and inline functions)
would be something that is independent of the C files. At the end of the
day all that really matters is the architecture C ABI.

That is, if rustc inlines a C function from a header, it doesn't matter
it used libclang to do so, even if the C files are then compiled with
GCC.

> And finally there is the question of what GCC Rust would do in such a
> case. Things have substantially changed on the GCC Rust in the last
> years, and they are now closer to build the kernel, thus I think their
> side of things is getting important to consider too.
> 
> Cc'ing Emilio (`bindgen`), Antoni (GCC backend) and Arthur (GCC Rust)
> so that they are in the loop -- context at:

Right, so clearly GCC has the capability to parse C headers :-) So I
would imagine their Rust front-end would be able to hand off C headers
and get back IR much like LLVM based projects can using libclang.



  reply	other threads:[~2025-12-04 12:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02 20:27 [PATCH 0/4] Inline helpers into Rust without full LTO Alice Ryhl
2025-12-02 20:27 ` [PATCH 1/4] vmalloc: export vrealloc_node_align_noprof Alice Ryhl
2025-12-02 20:27 ` [PATCH 2/4] rust: helpers: #define __rust_helper Alice Ryhl
2026-01-07 11:49   ` Andreas Hindborg
2025-12-02 20:27 ` [PATCH 3/4] kbuild: rust: add `CONFIG_RUSTC_CLANG_LLVM_COMPATIBLE` Alice Ryhl
2025-12-02 20:27 ` [PATCH 4/4] build: rust: provide an option to inline C helpers into Rust Alice Ryhl
2025-12-03  0:40   ` Matthew Maurer
2025-12-03 18:09   ` Gary Guo
2026-01-07 12:10     ` Andreas Hindborg
2025-12-03 21:25   ` Nathan Chancellor
2025-12-03 23:25     ` Matthew Maurer
2025-12-04  9:46     ` Alice Ryhl
2025-12-04 10:07   ` Peter Zijlstra
2025-12-04 10:23     ` Alice Ryhl
2025-12-04 11:11       ` Peter Zijlstra
2025-12-04 11:57         ` Miguel Ojeda
2025-12-04 12:39           ` Peter Zijlstra [this message]
2025-12-04 13:03             ` Alice Ryhl
2025-12-04 12:49           ` Emilio Cobos Álvarez
2025-12-04 13:15             ` Alice Ryhl
2025-12-04 14:27               ` Peter Zijlstra
2025-12-04 19:29                 ` Matthew Maurer
2026-01-07 12:23 ` [PATCH 0/4] Inline helpers into Rust without full LTO Andreas Hindborg
2026-01-07 12:35   ` Peter Zijlstra
2026-01-07 13:12     ` Andreas Hindborg
2026-01-07 13:18       ` Peter Zijlstra
2026-01-07 13:40         ` Andreas Hindborg
2026-01-07 13:42           ` Alice Ryhl
2026-01-07 14:01             ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251204123906.GL2528459@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=arthur.cohen@embecosm.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bouanto@zoho.com \
    --cc=dakr@kernel.org \
    --cc=emilio@crisal.io \
    --cc=gary@garyguo.net \
    --cc=josh@joshtriplett.org \
    --cc=justinstitt@google.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llvm@lists.linux.dev \
    --cc=lossin@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mmaurer@google.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=nicolas.schier@linux.dev \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=urezki@gmail.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.