-
Notifications
You must be signed in to change notification settings - Fork 164
Frequently Asked Questions
Rust currently lacks a full language specification. The Sealed Rust 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.
If GCC Rust interprets a program differently from rustc, this is considered a bug (at this stage of the project). Once Rust-GCC can compile and verify all Rust programs, this can also help figure out inconsistencies in the specification of features in the language.
The front-end could have leveraged the existing Rust code base and wrote bindings back to GIMPLE. 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. Nevermind a difficult bootstrapping problem in terms of the version of rustc supported for each release of GCC and regression testing of the GCC maintainers' front-end.
GCC could have been added to rustc as a new backend akin to cranelift using the GCC's new JIT interface. Adding GCC just as a backend to rustc would still keep it external to GCC and the GCC community. LLVM and GCC coexisting showed that those are culturally different groups. Adding a front end to GCC rather than a backend to rustc, we hope to get a second community invested in Rust, instead of putting more burden on the already significant Rust community. This option still has a bootstrapping issue as the interface does not support cross compilation.
All GCC code requires copyright assignment to the FSF and GPL Licensed making it difficult to merge with. Mrustc also uses RTTI features and C++14 which are also not supported within GCC codebase.
We are aware of this and believe now is the best time to implement alternative compilers since the focus on Rust's language stability.
Moreover 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 and attract further resourcing.
We aim to leverage https://github.com/rust-lang/polonius as a GCC plugin to avoid copyright assignment. Borrow checking is not required to produce code as its a compiler that naturally occurs through the design of the language.
There is no plan to implement the Rust standard library from scratch, but we will reuse the existing standard library akin to GCCGO usage of libgo. We can leverage the existing test suite from Rust to find gaps and inconsistencies in implementation.
Mixing Rust and C/C++ and CFI
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 GCC emits GIMPLE directly into a section of each object file, and LLVM does something similar but uses its own bytecode. In the case of mixing Rust compiler code and GCC built code in the Linux kernel, this will mean 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 can provide the gaps for in embedded development.