On Fri, Jul 15, 2022 at 11:02 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > Ok; I'm supposing that'll be sorted by the time rust happens. No, it most likely won't, and I don't see why you would assume that, or why we would want to block Rust support on that. > There's quite a few things affecting code-gen; rustc not using the exact > same compiler arguments is going to create a head-ache. Yes, a GCC-like driver in `rustc` would be nice for projects like the kernel. The GCC Rust project will support GCC-like flags, as far as I understand. (Cc'ing Antoni, Arthur, Josh, Philip). > But does it support everything clang does now? If not, you need to > express that in Kconfig and disable the features it doesn't carry. So > even for a single rustc version will you need RUSTC_HAS_ stuff. You could still make everything work around the `RUST` symbol, no need to "litter everything" (as you said) just yet. :) > What about CC_HAS_IBT? Can rust generate sane IBT code? Current next > doesn't seem to have anything there, suggesting I can't build an IBT > enabled kernel if rust is on (or rather, it'll build, but it'll also > burn at boot). > > What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust > doesn't have it? Same if LLVM finally stops generating those pesky > conditional tail-calls, will rust continue emitting them? > > I'm thinking of the kCFI work, will rustc support that from day 1 or > will that only work when not building any rust. > > There being a single rustc is not a single target, every compiler > version grows (and breaks) new features. And for some reason we seem to > change the actual kernel calling convetion a lot of late :/ > > Currently we can support a feature when one compiler version supports it > (either gcc or clang), but the moment rust becomes a mandatory part of > the kernel build (and I dread that day) we'll need to > wait/update/wrangle at least two different toolchains to implement the > feature in a consistent manner before we can use it. > > I also don't see any RUST -mfentry support... I think you are getting way too ahead. Merging the Rust support now is meant to evaluate whether Rust _as a language_ makes sense for the kernel, whether we can write enough % of kernel code in the safe subset (and whether that brings enough advantages), etc. It is not meant to provide "day 1 support" for everything. In fact, getting merged now is what will allow to grow support for everything needed everywhere: not just in terms of compiler flags, faster integration of LLVM codegen/mitigation features in `rustc`, new frontends and backends (`rustc_codegen_gcc` and GCC Rust), etc.; but also within the kernel, in terms of safe abstractions for kernel APIs, kernel maintainers' experience with Rust, etc. Cheers, Miguel
