Hacker News Reader

Comment by justincormack | Hacker News Reader

So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler?

Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.

View on HN

It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw...

Basically, you start from the last C version, and every version is supposed to be able to compile the next one.

Ah ok, so there will be a pretty long chain from 1.2 eventually, but hopefully it will be part of the test suite...

Usually you don't keep the chain. You just keep a working compiler. You can also bootstrap from another implementation of the language, e.g., gccgo.

A common trick is to keep a highly portable interpreted version of the target language and then use this for bootstrapping, but often you attack new architectures by cross-compilation instead. It all depends.

Also, it is common for self-hosting languages to require themselves to build.

You should always be able to build a Go 1.x compiler with just the 1.4 tool chain binaries. We have committed to sticking to the Go 1.4 language and libraries for the compiler tool chain.

Where is this fact documented? Are patches tested against 1.4 tool chain binaries?

Here https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA...

In the proposal section.

> Where is this fact documented?

http://tip.golang.org/doc/install/source#go14

> Are patches tested against 1.4 tool chain binaries?

The builders build the tool chain with Go 1.4, so the build dashboard will show failures if a patch incompatible with 1.4 is submitted. (We have pre-commit trybots that do the same.)

So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?

You can't avoid trusting trust. "Ken was here" :)

You actually can. Proof here: http://www.dwheeler.com/trusting-trust/

I was alluding to Ken being the author of the old, as well as one of the authors of the new compiler. In jest :)

You can. You just have to bootstrap all the way up.

What if any intermediate version is found to contain the violation of trusting trust? Every go maintainer has to build every version sequentially from that version to current version.

You could audit the Go source and then use the diverse double compiling technique[0] to verify that the binary you're using corresponds to that source code.

[0] http://www.dwheeler.com/trusting-trust/dissertation/html/whe...

You mean, audit a large number of independently-written Go compilers?

Nicely done. To be fair though, Go is just 6 years old and still evolving.

Exactly. Which is why I think it's important to keep the option of compiling its compiler from a language which has a large diversity of compilers.

I don't believe it has been tried yet, but it seems entirely possible to use gccgo as the bootstrap compiler.

Either cross compile, or get the last C-based Go compiler, and use that to build the more recent Go releases.

> So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler?

What's the bootstrap process for the C compiler part of the compiler?

The is no C code in the compilers anymore.

But if one has access to the Go compiler source, is it not a reasonable guess that one would be able to access a go compiler binary from the same trusted source? I just don't see this as a problem since it is impossible to build a computer from the ground up without trusting a lot of software first.

Probably gccgo, which is included in gcc.

For the purposes of bootstrapping.

Reply on news.ycombinator.com