Re: [TECH TOPIC] Rust for Linux

[Arnd Bergmann <arnd@arndb.de>]

On Wed, Jul 7, 2021 at 5:28 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Wed, Jul 7, 2021 at 4:32 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > I suppose using this for building kernels is actually easier than doing
> > an architecture port for user space, because it does not have to
> > wrap the syscall interface, right?
>
> What do you mean by architecture port? Do you mean native vs. cross-compiling?

No, I meant just which targets are enabled at all, regardless of whether
we are cross-building.

https://doc.rust-lang.org/nightly/rustc/platform-support.html lists only
arm64, arm32, hexagon, mips, powerpc, riscv, sparc64, s390x,
x86-32 and x86-64, in a number of variations (plus a few others
that don't run Linux). I assume these all have user space support,
while the other architectures that have llvm support (arc, csky, m68k,
sparc32) would work in principle for building the kernel but are lacking
a standard library port.

> > I've had a quick look at what it would take to integrate this into the prebuilt
> > toolchains on kernel.org to give developers the chance to try their rust
> > code across architectures. I've managed to cross-build the patched
> > gcc sources for rustc_codegen_gcc, but haven't actually figured out how
> > to build rustc_codegen_gcc itself.
>
> I discussed with Konstantin a while back about having the Rust
> toolchain in kernel.org too -- so I am glad you are looking into this.
>
> On `rustc_codegen_gcc`, it is early days -- I think all these projects
> just got accelerated a lot thanks to the possibility of Rust being in
> the kernel. But you can find information on this Compiler Explorer
> issue because they are also trying to set it up [1]. The author looks
> quite open to help us, so you may want to contact him too.
>
> [1] https://github.com/compiler-explorer/compiler-explorer/issues/2683

Ok

> > Before I look at this further, can you clarify what the version dependencies
> > are? I.e. if I want to build this for five gcc versions, 27 target
> > architectures,
> > and seven versions of rustc as shipped by the most common distros, can
> > I do this with a single rustc_codegen_gcc binary, or do I need to build
> > 5*27*7=945 versions of the binary, or something inbetween?
>
> I have not yet used `rustc_codegen_gcc` since it is not ready for our
> purposes. But:
>
>   - Only a single version of `rustc` is supported per kernel release
> (until we stop using unstable features), so that at the very least
> would cut down things by 7.

Ah, so I assume this is not going to be the version from my distro then.

>   - I would imagine the patched GCC of `rustc_codegen_gcc` only
> supports the latest GCC release, do we really want to try to use it in
> all GCC versions supported by the kernel? Of course, it would be great
> if that means we can support Rust everywhere, do not get me wrong!

Well, this was my question: if the libgccjit interface is stable enough,
it should be possible to port the patches to every version we still
support in the kernel. gcc-4.9.4 does not have libgccjit, but the later
ones do.

The patches are only for an unreleased gcc-12 tree but they
don't look too invasive, so maybe they could eventually get
backported to stable compilers (not upstreamed, but at least
used for my builds).

I don't really care about the outdated fix releases (9.3, 8.4,
7.3, ...) but I try to make sure the latest build of each major
gcc version works.

>   - I don't know how stable the `libgccjit` interface is -- if it is,
> then we only need a single one, as you say. I would ask the author.

According to
https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html
the ABI should be stable across all gcc versions, so if we
can get it to work with an old gcc release it would work with
all newer ones as well, but obviously anything built against the
patched library won't work against a newer version of the library
if that doesn't also have those patches.

My guess is that the ABI is also stable across target architectures,
but I could not confirm that. If this is true, then building against
the oldest supported libgccjit would make it work with any later
(patched) libgccjit, but we'd need to pass the correct libgccjit.so
file that matches the gcc version used for building the kernel
and the target architecture.

>   - We could try to get upstream GCC to accept the patches needed to
> make `rustc_codegen_gcc` work, though I am not sure how well they
> would be received, since they are working on their GCC Rust frontend
> too.

This would clearly only work for gcc-12 or later, otherwise it
does seem plausible. As far as I can tell, the patches just add features
that may be generally useful, not just for rust.

     Arnd