Frequently Asked Questions - Rust-GCC/gccrs GitHub Wiki

Targeted Language Version

Rust currently lacks a full language specification. The Ferrocene project by Ferrous Systems (https://ferrous-systems.com/blog/sealed-rust-the-pitch/) is the first step in that direction. If Rust-GCC can help with that, we're happy to work together and move the formal specification forward.

Until this happens, rustc and The Rust Reference will be used as the Rust-GCC development specification.

What is the plan for inconsistencies in behaviour?

If gccrs interprets a program differently from rustc, this is considered a bug.

Once Rust-GCC can compile and verify all Rust programs, this can also help figure out any inconsistencies in the specification of features in the language. This should help to get features right in both compilers before they are stabilized.

The GCC Rust project is not and will not provide a shortcut for getting features into the Rust language. It will follow the well established processes, i.e. RFCs.

NOTE: There are situations where it is not clear if something is a language feature. Those will be carefully considered on a case by case basis.

Why not write the front-end in Rust using the existing compiler?

The front-end could have leveraged the existing Rust code base and wrote bindings back to GCC's GENERIC. rustc MIR is currently unstable, which leaves a question to the level of stability in lowering MIR to GIMPLE with successive releases of both GCC and Rust. Additionally, there would be a difficult bootstrapping problem in terms of the version of the Rust language support for each release of GCC, which would require regression testing of the GCC maintainers' front-end.

Why was adding GCC backend for rustc -- rejected?

GCC could have been added to rustc as a new backend akin to cranelift using GCC's new JIT interface. Adding GCC as a backend to rustc would not solve the issue of its separation from GCC and the GCC community. LLVM and GCC coexisting shows that they are culturally different groups. By adding a front end to GCC rather than a backend to rustc, we hope to get a second community invested in Rust.

There were also technical considerations for this choice. GCC does not support cross-compilation in the same way LLVM does, in which a library gets loaded with hooks for the target host. This could lead to difficult packaging problems for this approach.

Note: a libgccjit backend was accepted into rustc in June 2021.

Why not use mrustc?

mrustc has a different goal to GCC Rust. mrustc aims to bootstrap rustc, and hence provides minimal error and warning diagnostics to the programmer.

All GCC code requires GPL licensing, making it difficult to merge with. mrustc also uses features such as RTTI and C++14, which are not supported within the GCC codebase.

Re-implementing a front-end from scratch is a daunting project

We are aware of this and believe now is the best time to implement alternative compilers due to the focus on Rust's language stability.

Moreover, we hope that with the announcement from Open Source Security, inc and Embecosm hiring Philip Herron for one year to bootstrap the project will get the compiler's core features done and attract further resources.

Mitigation for Borrow Checking

We aim to leverage Polonius. Borrow checking is not required to produce code.

Mitigation for Standard Lib

There is no plan to implement the Rust standard library from scratch - we will reuse the existing standard library, similar to GCCGO's usage of libgo. We can also leverage the existing test suite from Rust to find gaps and inconsistencies in our implementation.

Benefits

Mixing Rust and C/C++ and CFI

With the recent announcement of Rust being allowed into the Linux Kernel codebase, an interesting security implication has been highlighted by Open Source Security, inc. When code is compiled and uses Link Time Optimization (LTO), GCC emits GIMPLE directly into a section of each object file, and LLVM does something similar with its own bytecode. If mixing rustc-compiled code and GCC-built code in the Linux kernel, the compilers will be unable to perform a full link-time optimization pass over all of the compiled code, leading to absent CFI (control flow integrity).

If Rust is available in the GNU toolchain, releases can be built on the Linux kernel (for example) with CFI using LLVM or GCC.

References:

• https://msrc-blog.microsoft.com/2020/08/17/control-flow-guard-for-clang-llvm-and-rust/
• https://www.cs.ucy.ac.cy/~eliasathan/papers/tops20.pdf

GCC Plugins

Existing GCC plugins such as those in the Linux Kernel project should be reusable since they target GIMPLE in the middle-end.

rustc - Bootstrapping

It could be possible to bootstrap the official rustc compiler using GCC Rust.

Backend Support

LLVM is missing some backends that GCC supports, so a GCC Rust implementation can fill in the gaps for use in embedded development.

Backporting

This front-end is tightly integrated with GCC and could be backported to at least when gccgo was introduced. This can drive the adoption of Rust in cases where vendors only have a GNU toolchain they will receive a rust front-end for free as part of the upstream efforts.