Reading Assembly

Seeing the output: -S

The compiler will show you the code it generates. Two equivalent ways:

# Disassemble one file (prints to stderr).
go tool compile -S main.go

# As part of a build, for whole packages.
go build -gcflags=-S ./...

# Combine with -m to also see inline/escape decisions.
go build -gcflags='-S -m' ./...

A snippet for a trivial add function looks roughly like this (amd64):

"".add STEXT nosplit size=4 args=0x10 locals=0x0
  MOVQ  "".a+8(SP), AX   ; load arg a from the stack frame
  ADDQ  "".b+16(SP), AX  ; add arg b
  MOVQ  AX, "".~r0+24(SP) ; store the return value
  RET

It’s Go’s abstract assembly

What you’re reading is not literal x86/ARM — it’s Go’s own portable assembly notation (inherited from Plan 9), shared across architectures and then lowered to the real instruction set. The giveaways are the pseudo-registers:

nosplit means the function skips the stack-growth check; args/locals give frame sizes. The mnemonics (MOVQ, ADDQ, CALL) resemble the platform’s but go through Go’s assembler, so don’t expect a 1:1 match with objdump.

Anchoring with runtime function info

You can’t run -S inside a playground, but you can introspect compiled functions at runtime — names, entry addresses, and source positions — which is the same metadata the disassembler and stack traces use:

package main

import (
"fmt"
"runtime"
)

//go:noinline
func add(a, b int) int {
whoAmI()      // print this function's compiled metadata
return a + b  // ...the work the assembly implements
}

// whoAmI reports the name, file and line of its *caller* using the
// same PC→function metadata that stack traces, panics and pprof use.
func whoAmI() {
pc := make([]uintptr, 1)
n := runtime.Callers(2, pc) // skip Callers + whoAmI, capture the caller
if n == 0 {
	return
}
fn := runtime.FuncForPC(pc[0])
file, line := fn.FileLine(pc[0])
fmt.Printf("running %-14s at %s:%d (entry 0x%x)\n",
	fn.Name(), shortFile(file), line, fn.Entry())
}

func shortFile(p string) string {
for i := len(p) - 1; i >= 0; i-- {
	if p[i] == '/' {
		return p[i+1:]
	}
}
return p
}

func main() {
fmt.Println("add(2,3) =", add(2, 3))
fmt.Println("the entry address above is where add's assembly begins.")
}

The clean, supported path is runtime.FuncForPC on a PC you already hold (here, from runtime.Callers). The takeaway: every compiled function carries name/file/line metadata and an entry address, which is exactly what go tool compile -S, panics, and pprof use to map machine code back to your source.

What to look for

When you do read assembly, you’re usually checking one of a few things:

• Did it inline? A small hot function should not appear as a CALL in its caller. -gcflags='-m' says “can inline X”; -S confirms it’s gone.
• Bounds-check elimination (BCE). Loops over slices should drop the CMP/panic-branch when the compiler can prove the index is in range. -gcflags='-d=ssa/check_bce/debug=1' reports remaining checks.
• Did an intrinsic fire? math/bits.TrailingZeros, bits.OnesCount, atomics — these should be single instructions, not calls.
• Did it allocate? A CALL runtime.newobject in a “fast” path means something escaped.

See also

• compile & link — the pipeline that produces this assembly.
• escape analysis — spotting runtime.newobject calls that mean an allocation.
• memory layout & alignment — why field offsets show up as (FP) displacements.
• benchmarks (stdlib) — the measurement that should precede any assembly reading.

Next: the whole track on one page — the internals cheat-sheet.

Related topics