Rust Support Is Being Built into the GNU GCC Compiler | Hacker News Reader

Rust Support Is Being Built into the GNU GCC Compiler

thenewstack.io

I like Rust. I use it daily, at work and for personal projects.

I can definitely see many advantages in Rust that would add value to the Linux kernel. However, I feel like there are two definite things currently missing in the language that need to be implemented ASAP for the rust + linux kernel story to truly work.

Panics (Rust's term for exiting a program when encountering an unhandled error) are a good idea in most environments - instead of reading or writing past a vector's last element, the program immediately exits. This approach falls through when you're in an incredibly high stakes environment that must absolutely avoid crashes. Sure, you can catch some panics [0], but you can not easily avoid them entirely. There is no surefire way to know if subroutines any level deep may panic. Linus himself mentioned this problem, so I think handling it should be a top priority.

What's also definitely missing is an allocator strategy. Zig is a good example for this, you can choose the exact allocation method that fits your model.

[0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html#not...

Wouldn't it be possible to make gcc (optionally?) add https://docs.rs/no-panic/latest/no_panic/ to every function it compiles? Sure, that may make most Rust code not compile, but for kernel devs, this may not be too much of a hindrance as they may only use a small subset of crates which could be all made compile with this option.

If you read the caveats section of the crate, you will find that it is quite limited in its capabilities. I firmly believe that panic-free guarantees need to be built into the compiler with a special flag.

Linux has kernel panics, and they predate Rust. You can't just dereference NULLs or spray random memory and still "absolutely avoid crashes". If you let C code write past end of a vector, you will have an unstable system and data corruption.

Catching these bugs before they cause damage is an improvement to stability. In Rust you can compartmentalize panics. Instead of messing up the whole kernel or causing a machine-halting kernel panic, you can gracefully unwind one call and execute a fallback or return an error code from the one syscall that hit the bug. That is how you can continue running the kernel reliably instead of hoping to get lucky.

Then, there was a miscommunication between the Linux Rust project and Linus, about an issue that does not exist any more. An early draft had a handler that translated OOM to kernel panics as a kludge from use of Rust's standard library containers as a placeholder for proper containers being developed. Linus rightly criticized that this was a bad idea, but it was never meant to be the final setup. That code has been replaced now, and Rust in the kernel uses fallible allocation that does not abort nor panic. The issue does not exist in the no-alloc Rust dialect used in the kernel going forward.

You are entirely correct.

Great! Multiple implementations are an important part of a healthy long term sustainable language. Even when they are niche offshoots that don’t gain wide adoption, they represent enough of a demand in terms of people writing code in that language and a supply of engineering talent and time to make a solution that better fits the niche they need filled. Just look at Python, there’s Jython, IronPython, PyPy, nuikta, Cython, micropython, and so many others all with varying degrees of longevity and success. All of which started with an unfulfilled need and some development efforts to supply that need.

Rust by way of GCC is great news and will do wonders for helping Rust expand further into the C/C++ dominated world of embedded programming where a lot of hardware lacks the support of LLVM and thus Rust proper.

I wonder though --- will GCC have to comply with a specific API of cargo? Wondering if this will end up being an awkward kind-of RUSTC="gcc rust" cargo build thing, or if this will be some lower level API.

I don't think rust-gcc will support Cargo, it will probably be the other way around. Generally, if you want to have an idea at how rust-gcc will look like and how it will be integrated into the wider ecosystem, you can take a look at gccgo, which is a GCC frontend for Go developed and supported by the core Go developers. However I don't have any experience with using it, so I can't tell you a lot about it besides that it exists...

We have `cargo-gccrs` for this, so a cargo subcommand which intercepts arguments given to `rustc` and converts them into `gccrs` arguments :)

https://github.com/rust-GCC/cargo-gccrs/

it's still in a relatively early stage as we are focusing on the compiler. But the idea is for it to be a drop-in replacement for compilation and execution operations, so you'd have `cargo gccrs build`, `cargo gccrs run`, `cargo gccrs test`, etc

Why are they dedicating work for this? Is there something wrong with rustc?

Reply on news.ycombinator.com