Unstable compilers

Posted Sep 24, 2024 18:39 UTC (Tue) by sam_c (subscriber, #139836)
Parent article: Committing to Rust in the kernel

> Airlie said that it is too soon to ask the Rust community for a completely stable compiler to build kernel code with; there just is not yet enough Rust code in the kernel to make that happen.

I don't understand this, this feels like it ought to be a prerequisite. If the language isn't ready yet with the pace at which it moves and the lack of a LTS release compiler, perhaps it isn't ready for the kernel yet either.

to post comments

Unstable compilers

Posted Sep 24, 2024 21:44 UTC (Tue) by Baughn (subscriber, #124425) [Link] (11 responses)

This describes C, for most of the history of thethe kernel.

Unstable compilers

Posted Sep 25, 2024 1:02 UTC (Wed) by sam_c (subscriber, #139836) [Link] (10 responses)

Please elaborate. I am unfamiliar with the C you describe.

Unstable compilers

Posted Sep 25, 2024 5:16 UTC (Wed) by admalledd (subscriber, #95347) [Link] (9 responses)

TL;DR: Until "recent history" of about as recent as ten years ago, compiling the Linux Kernel had a very odd list of "these are the only compiler versions *known* to work correctly, try any others and they are between you and the mantissa of your FPU doing a DIV 0". Such as specific patch levels of GCC or CLANG.

You could (especially as you approach the modern era) still often *compile* with whatever GCC (and sometimes CLANG) version so long as it was above some horribly old bare minimum, but it was not uncommon to have subtle miscompilations in more esoteric drivers, or flat out some drivers not compiling, etc.

Many forget this, because distros would baseline on these known-good compiler versions, so the majority of users would never know, often even kernel developers.

Unstable compilers

Posted Sep 25, 2024 9:32 UTC (Wed) by sam_c (subscriber, #139836) [Link] (6 responses)

Thanks. I guess I'd make the distinction between new features only available in and bugginess though.

Unstable compilers

Posted Sep 25, 2024 9:32 UTC (Wed) by sam_c (subscriber, #139836) [Link]

I meant to add: ... because you can more easily backport bug fixes.

Unstable compilers

Posted Sep 25, 2024 9:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (4 responses)

> I guess I'd make the distinction between new features only available in and bugginess though.

You need to add to that list "new features either enabled by default, or often enabled by force, that break the kernel".

One only has to look at all the complaints about UB, where gcc was optimising code away. Quite often (a) this stuff was NEEDED, and (b) there was no flag to disable the optimisation responsible for removing them.

So the compiler wasn't buggy, it was working as designed. And if the die-hards are going to complain and say "well Rust needs to call C to access the hardware", it was not at all unusual for C to have to call assembler to access the hardware, because the C compiler was just deleting the code as UB with no way to stop it. Hence my comments in various places about mathematics is not reality.

The difference is, it appears the Rust devs seem much more amenable to treating "you're optimising away necessary code" as a bug than the C folks were.

Cheers,
Wol

Unstable compilers

Posted Sep 25, 2024 9:52 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (3 responses)

> it appears the Rust devs seem much more amenable to treating "you're optimising away necessary code" as a bug than the C folks were.

The optimization backend in the end is the same, the difference is that the language itself is designed to make it harder to trigger undefined behavior.

For example the level of aliasing is declared explicitly by separating shared and exclusive references (& and &mut). Developers can only turn a shared reference into an exclusive one via UnsafeCell (and then the code needs to be explicitly marked as unsafe) or wrappers thereof (which are carefully designed to avoid undefined behavior).

Unstable compilers

Posted Sep 25, 2024 10:42 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

> > it appears the Rust devs seem much more amenable to treating "you're optimising away necessary code" as a bug than the C folks were.

> The optimization backend in the end is the same, the difference is that the language itself is designed to make it harder to trigger undefined behavior.

Maybe that's the effect. But even today the C devs seem keen on creating new undefined behaviours. In Rust, undefined behaviour is viewed as a bug in the language (or as "you can only do that in an unsafe block") as far as I can tell. Completely diametric views on UB.

Cheers,
Wol

Unstable compilers

Posted Sep 25, 2024 18:10 UTC (Wed) by sunshowers (guest, #170655) [Link]

Yes, that is correct, and Rust is better for it. Under the assumption that unsafe code is correct, safe code doesn't have UB.

I would rather optimization 'alpha' be extracted through principled approaches like enabling the use of "restrict" on &mut pointers.

Unstable compilers

Posted Sep 26, 2024 20:04 UTC (Thu) by ralfj (subscriber, #172874) [Link]

> In Rust, undefined behaviour is viewed as a bug in the language (or as "you can only do that in an unsafe block") as far as I can tell. Completely diametric views on UB.

Yes -- mostly the latter. I think Undefined Behavior is a great tool for language designers; they can use it to enable powerusers to get the compiler to do things you'd never (well, not practically) get it to do without. But it is the language designer's responsibility to yield this tool with care.

A more lengthy discussion of this point is in my blog: https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html

In C, things can be UB either because the standard says they are UB, or because the standard is entirely silent about that case. The latter is considered a spec bug in Rust, it is not acceptable for us to have things be "implicitly" UB. The former still happens, but we are doing our best to describe those cases as unambiguously as possible. Rust doesn't have a spec yet, so we still have a lot of work ahead of us, but Miri [1] helps a lot: if we understand our UB rules well enough to wire them into a tool that can automatically test for UB, that's a great first step towards an unambiguous specification! I think something like Miri would be nearly impossible to do for C, since the standard is just not sufficiently clear about many corner cases.

[1]: https://github.com/rust-lang/miri/

Unstable compilers

Posted Sep 25, 2024 17:56 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

> You could (especially as you approach the modern era) still often *compile* with whatever GCC (and sometimes CLANG) version so long as it was above some horribly old bare minimum, but it was not uncommon to have subtle miscompilations in more esoteric drivers, or flat out some drivers not compiling, etc.

Because all rust compilers are guaranteed to be bug-free ?

Unstable compilers

Posted Sep 25, 2024 18:29 UTC (Wed) by admalledd (subscriber, #95347) [Link]

Certainly not, but the stability of `rustc` is often much higher than many give it credit for, and that Rust gives much better ABI(*)/linking guarantees. It is often not plausible to use a different GCC version from what compiled the kernel to compile custom modules for example. Rust can provide much stronger guarantees here by default, though as mentioned in the article there is in-kernel work to be done for the module symbol naming/linking.

Rust in *most* cases will either halt compilation with an Error, and InternalCompilerError, or result in symbols that will fail at linking time instead of (used to be more) commonly "compiling" fine but crashing/failing at runtime or `insmod` time.

* Rust technically has no ABI, but you can expose/use one via various exports/macro things, commonly of course a "c-abi". This is mostly handled by `rust-bindgen` for automation with a dash of human control when required.

Unstable compilers

Posted Sep 25, 2024 12:47 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Take for example 128-bit integer support. Rust has 128-bit integers. Code to handle these e.g. formatting them for output as text - exists but in a typical Rust application which doesn't actually have any 128-bit integers the code for them never ends up in the resulting binary.

But, Linux currently just says nope, we'll take everything just in case, because a loadable module might use it. A few kilobytes of formatting for types we never use? Give me those too.

So for Stable Rust Linux would get a bunch of 128-bit integer formatting code it has no use for, on the off chance that somebody might some day write a loadable module which expects 128-bit integer formatting to work. In Rust for Linux they've instead just made this code conditional and switched off the condition, it won't compile in your loadable module and the kernel avoids a few kilobytes of "format 128-bit integers" code.

The push back from the Rust community is they're not interested in doing a bunch of extra work to help people who want all the symbols but then wish somebody else would do the work to slim it down for them, pick a lane. So the Rust for Linux change will never land in the stable Rust in this form.