Chapter 3 The Life of a Program on Go: Under the Hood

3.1 Starting from the `go` Command

Mon, 01 Jan 0001 00:00:00 +0000

3.1 Starting from the `go` Command

The life cycle of a Go program begins with running the go command. The go build, go test, and go run that readers type every day look like they merely “turn source into a binary,” but behind them hides a fact that is often misunderstood: go itself is not the compiler. It is a build orchestrator, responsible for breaking a single build into many individual steps, arranging their ordering and parallelism, and then invoking the real tools one by one: the compiler compile (3.2), the assembler asm, and the linker link (3.4). This section first makes this orchestration relationship clear, as it is the master outline for the sections that follow: once you understand how go decomposes a build into a graph and how it uses a content-addressed cache to avoid duplicate work, then turning to the details of compilation and linking gives you a frame to stand on.

3.2 The Go Compilation Pipeline

Mon, 01 Jan 0001 00:00:00 +0000

3.2 The Go Compilation Pipeline

3.1 explained that the real work behind go build is carried out by two programs, compile and link. This section zooms in on compile and traces the full journey from a single .go source file to a single .o object file: what each stage receives, what it produces, and why the work is cut up this way. This section is a panorama of the compilation pipeline. The inner workings of each stage (how the grammar is designed, what algorithm type checking uses, the optimization rules of SSA) are left to Chapter 15 to unfold one by one. Here we only string them into a single line and point out two threads that run through all of it.

3.3 Bootstrapping the Language

Mon, 01 Jan 0001 00:00:00 +0000

3.3 Bootstrapping the Language

One question sounds like a paradox: Go’s compiler, assembler, linker, and runtime are all written in Go today, so where did the first program capable of compiling Go come from? Without a Go compiler, how do you compile a Go compiler? This is bootstrapping. It is both the classic chicken-and-egg dilemma and a piece of engineering in the history of the Go toolchain that can be retold precisely. This section answers three things: how this egg was first hatched; how, after bootstrapping, the chain for building a new version of Go works, and why the demands it places on the bootstrap version keep rising year over year; and finally, why a language that “implements itself with itself” deserves to be taken seriously.

3.4 Module Linking

Mon, 01 Jan 0001 00:00:00 +0000

3.4 Module Linking

The compiler (3.2) turns each package into an object file, but an object file cannot run on its own. The object files still reference one another’s functions and variables, addresses are not yet fixed, and the runtime support is still missing. Assembling these fragments into a complete program that can be loaded and executed is the job of the linker (cmd/link, usually invoked by go build as go tool link). This section looks at what the linker does, and at a few choices Go makes around linking that together explain why a Go program is so often a self-contained file that “just runs once you copy it over.”

3.5 Bootstrapping a Go Program

Mon, 01 Jan 0001 00:00:00 +0000

3.5 Bootstrapping a Go Program

The main function the reader writes is not the program’s true first instruction. When the operating system hands control to a Go executable, what starts running is the runtime: it has to lay out the execution stack on the main thread, bind thread-local storage, measure the CPU core count and the physical page size of memory, wake up the memory allocator, the garbage collector, and the scheduler one by one, and only then create the goroutine that carries main and hand it to the scheduling loop to run. In other words, a Go binary carries within it a miniature operating system (1.2), one that starts itself up ahead of user code. This section walks the bootstrap chain from end to end, from the operating system’s entry symbol to the moment the first goroutine is scheduled, so we can see clearly what happens “before main.”

3.6 The Life and Death of the Main Goroutine

Mon, 01 Jan 0001 00:00:00 +0000

3.6 The Life and Death of the Main Goroutine

In 3.5, once schedinit has assembled the runtime’s foundations, it does not call runtime.main directly. Instead it pushes that function’s entry address onto the stack, hands it to newproc to fabricate the first Goroutine, and then lets mstart start the scheduling loop and pick this Goroutine out to run. The details of scheduling are left for 9 Scheduler. This section trains the camera on a single moment: the first Goroutine is already running, and it is about to execute runtime.main.

Chapter 3 The Life of a Program on Go: Under the Hood

3.1 Starting from the `go` Command

3.1 Starting from the go Command

3.2 The Go Compilation Pipeline

3.2 The Go Compilation Pipeline

3.3 Bootstrapping the Language

3.3 Bootstrapping the Language

3.4 Module Linking

3.4 Module Linking

3.5 Bootstrapping a Go Program

3.5 Bootstrapping a Go Program

3.6 The Life and Death of the Main Goroutine

3.6 The Life and Death of the Main Goroutine

3.1 Starting from the `go` Command