Nouveau - Dec 2025 - [PATCH 4/4] build: rust: provide an option to inline C helpers into Rust

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 at
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.

On Thu, Dec 04, 2025 at 01:39:06PM +0100, Peter Zijlstra
wrote:
> 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 at
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?
Rustc and bindgen are both part of the Rust project, but they're two
different repos:
https://github.com/rust-lang/rust
https://github.com/rust-lang/rust-bindgen

Generally you need to ensure that bindgen matches clang. This ensures
that bindgen and clang agree on the interpretation of C headers.
> > 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 ;-)
Maybe clang itself should have an option to emit Rust headers, taking
over the role of bindgen?

/me runs like crazeh ;-)

Alice