4 ms·

> Further, mrustc is only capable of targeting x86. Performing this reduction is thus impossible on riscv or aarch64, and for bootstrapping on these platforms,

> Further, mrustc is only capable of targeting x86. Performing this reduction is thus impossible on riscv or aarch64, and for bootstrapping on these platforms, one would have to build every single version of rustc. That reminds me. Couldn't the bootstrapping problem be solved by making an official, certified wasm build of the rust compiler, and distributing a signed binary of that build? That way your bootstrap chain only needs two steps (wasm interpreter hand-coded in local assembly, running the compiler binary -> actual compiler). It's safe, assuming you trust the source producing the wasm binary, or run a bootstrap chain to produce the binary yourself. It can target any architecture, provided you can get/write a wasm interpreter for it (not too hard). It certainly doesn't see like a problem where the most cost-efficient solution is to rewrite an entire compiler, frontend and backend, in a different less-convenient language.

nine_k 5y ago
I think this is seriously underappreciated approach.
DSMan195276 5y ago
Personally I feel like we're missing something (and I did read the article, for the record). I suspect the problem is that they either cannot produce a Rust cross-compiler (but I think that exists?), or such a compiler cannot compile Rust itself correctly for some reason. So in your case, I guess you must not be able to create a `wasm` version of Rust that is capable of compiling the Rust compiler to native code on whatever platform you picked. Otherwise your logic is basically how other compilers get bootstrapped, just replace `wasm` with some other already-supported platform like x86 - Produce an x86 to ARCH cross-compiler and compile the compiler with the new cross-compiler. The result is a compiler that runs on ARCH.
- comex 5y ago
  What you're missing is, mainly, the so-called "Trusting Trust" attack, where a compiler is backdoored such that whenever it's used to compile another compiler, the same backdoor is inserted into that compiler. Thus even assuming good intentions on the part of the current Rust maintainers, a backdoor could hypothetically have been inserted into version X's official compiler binaries at some point, which then infected version X+1, which infected version X+2, and so on. I say hypothetically, because IIRC Rust's bootstrap chain has been replicated, including with mrustc, resulting in identical binaries. There is absolutely no need to re-replicate it on every random architecture. (And even if you did want to do so, qemu already exists and can emulate x86, though wasm might be slightly faster.) But some people have strange ideas about how bootstrapping ought to work...
  - DSMan195276 5y ago
    Ah, I didn't catch the part of the article that pointed out not relying on existing compilers was an explicit goal (Which probably should have been obvious in hindsight). To each his own, it's still a fun project if not particularly practical. But that makes sense then that this probably isn't the only way to bootstrap Rust onto a new architecture.
pabs3 5y ago
The goal for Bootstrappable Builds is to not rely on compiled binaries, except for a small easily auditable 512-byte binary seed, and from there, and source code without any generated files, build an entire Linux distro: https://bootstrappable.org/ https://bootstrappable.org/ https://bootstrapping.miraheze.org/ https://bootstrapping.miraheze.org/

nine_k 5y ago

I think this is seriously underappreciated approach.

DSMan195276 5y ago

Personally I feel like we're missing something (and I did read the article, for the record). I suspect the problem is that they either cannot produce a Rust cross-compiler (but I think that exists?), or such a compiler cannot compile Rust itself correctly for some reason. So in your case, I guess you must not be able to create a `wasm` version of Rust that is capable of compiling the Rust compiler to native code on whatever platform you picked. Otherwise your logic is basically how other compilers get bootstrapped, just replace `wasm` with some other already-supported platform like x86 - Produce an x86 to ARCH cross-compiler and compile the compiler with the new cross-compiler. The result is a compiler that runs on ARCH.

comex 5y ago
What you're missing is, mainly, the so-called "Trusting Trust" attack, where a compiler is backdoored such that whenever it's used to compile another compiler, the same backdoor is inserted into that compiler. Thus even assuming good intentions on the part of the current Rust maintainers, a backdoor could hypothetically have been inserted into version X's official compiler binaries at some point, which then infected version X+1, which infected version X+2, and so on. I say hypothetically, because IIRC Rust's bootstrap chain has been replicated, including with mrustc, resulting in identical binaries. There is absolutely no need to re-replicate it on every random architecture. (And even if you did want to do so, qemu already exists and can emulate x86, though wasm might be slightly faster.) But some people have strange ideas about how bootstrapping ought to work...
- DSMan195276 5y ago
  Ah, I didn't catch the part of the article that pointed out not relying on existing compilers was an explicit goal (Which probably should have been obvious in hindsight). To each his own, it's still a fun project if not particularly practical. But that makes sense then that this probably isn't the only way to bootstrap Rust onto a new architecture.

pabs3 5y ago

The goal for Bootstrappable Builds is to not rely on compiled binaries, except for a small easily auditable 512-byte binary seed, and from there, and source code without any generated files, build an entire Linux distro: https://bootstrappable.org/ https://bootstrappable.org/ https://bootstrapping.miraheze.org/ https://bootstrapping.miraheze.org/