Bootstrapping Rust
gnu.org
gnu.org
This is the kind of work that seems pretty thankless, but I'm glad someone is doing it.
[1] https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
How does this work?
Is the source compiler bootstrapped from its source, such that the source compiler compiles the source of the source compiler and that results in the source compiler?
I think I’m getting confused because “source compiler” describes what a compiler does anyway, so I’m guessing that “source” in “source compiler” is used as in origin and not as in textual code, rather than a redundancy? So which source is the source compiler compiling?
This can be generalized to N compilers, so to truly claim that your compiler is safe, you’ll need to verify the source of all compilers in the chain.
I’m not an expert, so please correct me if I’m off here!
Theoretically (not very practical due to size) you could translate the compiler text that you see to machine executable code yourself, looking at some opcode reference.
OP: If you have the source compiler, which is itself bootstrapped from source, then you effectively sidestep the problem brought up in the paper.
So does that translate to English as:
You have the source code for a compiler. You’ve ensured that the source code isn’t tainted in any way. If you translate that source code into an executable binary by hand, then you know that binary isn’t tainted. And subsequently, that binary won’t taint its output.
?
Hmm. That just doesn’t seem interesting. And, as you say, “Theoretically... you could...”. Emphasis mine...
This result just doesn’t seem interesting. Not only do you have to verify the source of all compilers in the chain, you need to ensure that - when that code is compiled - it’s the exact source that was verified.
And even then, how do you know that the disk firmware actually gives you that non-tainted compiler when you ask for it?
But: I guess it’s turtles all the way down. This at least theoretically improves how much of the chain (from atoms on a disk to the binaries produced by your Nth compiler) is non-tainted.
That being said, that problem can be worked around by throwing interpreters into the mix.
Especially one that spits out a white supremacy message every once in a while: https://www.quora.com/What-is-a-coders-worst-nightmare/answe...
“Strappable” has 2 P’s... Link: https://bootstrappable.org/
Was some feature added to rust 1.20.0 that was particularly difficult to implement? Or is this just a 'have to stop somewhere' situation.
mrustc is effectively written entirely by one person: https://github.com/thepowersgang/mrustc/graphs/contributors
It's extremely impressive, but I can also understand why trying to keep up doesn't make a ton of sense.
You're releasing about 8 a year (excluding bug fix releases), each of which is necessary to compile the next one, and so on down the line? That sounds like it's going to get extremely nasty, really quickly.
mrustc has already bootstrapped a byte-identical rustc from the mainline, that in and of itself is good enough for many. Even Debian didn’t do a full bootstrap from the OCaml days.
It’s all about trust. If you want to be mega paranoid, then yeah it’s gonna be a lot of work. But that always is. This whole thing is only an issue for a very small number of people. Those people are important! But it’s a tradeoff, like everything.
Bootstrap for g++ is presumably something like machine code->asm->c->g++.
And the overall goal is something like shortening or simplifying the chain from machine code to rust compiler.
Ideally I suppose this would be something like machine code->proto rust->rust compiler.
Haskell seems to have a relatively good pipeline, with clean division between core and non-core.
https://www.reddit.com/r/haskell/comments/a600zp/thoughts_on...
We’ve been slowing down the requirements over time; the current policy is that you can build any stable with the previous release. Maybe someday we’ll slow it down further, but there’s no plans to do so any time soon.
Look, I'm a reasonable guy. I don't insist on being compatible with Linux 2.4, I don't insist on working with a compiler and system libraries from 2006, I don't reject all bundling completely. But working with stuff from a few years ago would be very helpful to lots of projects and efforts, and is what I've come to expect from high quality software distributions and libraries, like Debian stable, the linux kernel, GCC, libpng, sqlite3, etc etc.
(The linux kernel is a huge project and maybe the fastest-moving in existence, and you can build the very latest release with GCC-4.7!)
If Rust was a "traditional" project and not following web-ecosystem practices, it would still be issuing 0.x releases though - the language itself is quite far from true maturity (the "2018" version has only just gained NLL, and there are plenty of deeply-impacting features in the pipeline, at various stages of development). So it's six of one, half a dozen of the other...
“non-lexical lifetimes”
Think of it as LLVM declaring it has a hard dependency on the Linux kernel from last week (that isn't in a release yet).
I can be quite productive with C and Python from 10 years ago. Most Go I programs I write happen to be compatible with Go-1.7 from 2016, but I could go back to Go-1.4 from 2014 without much trouble if I had a reason to. Coincidentally, you can build the latest Go toolchain with Go-1.4, which was the last version written in C. I guess the Golang authors are just superhuman engineers, huh ...
For context, Rust 1.31 is sorta like the Go 2 release. It’s a much bigger deal than regular releases.
If you're writing infrastructure, please don't. (e.g. Firefox ... or the toolchain itself)
I'm one of those guys with no particular interest in Go 2. I really have plenty to work with already.
Some organizations change compilers very slowly, and you can't assume you always have the most updated compiler.
For example, when writing a library for my org I assumed that GCC 5.4 (2016) is a reasonable lower bound, and I used the appropriate set of supported C++11 features, and twice I had to downgrade as different teams notified me they had older and older compilers. (and couldn't upgrade)
> Were all rust users really naive/dumb to think that rust 1.29 was any good at all? Only 2 months later they never want to write Rust 1.29 ever again!
Rust 1.29 was fast and secure, but it also was annoying to write. Lexical lifetimes forced the structure of your code into a shape that sometimes required unnatural contortions. Basically everyone who wrote code in it could tell that something was definitely wrong. We still used it, because the other things Rust provided was worth the contortions. It was just a tradeoff you had to make. NLL, provided in 1.31, essentially removes the problem, making the other side of the tradeoff free. While previous versions of the Rust weren't horrible, 1.31 is massively better than them.
GCC is written in C++ though.
It compiles rust to C, so why not write it in rust? then compile itself to C.
Another idea, just compile rustc to web assembly then use https://github.com/WebAssembly/wabt/tree/master/wasm2c to convert it to your bootstrap source.
Exactly to avoid having any rust compilers in the chain.