What causes "unknown load address" in golang/go?

Link the `.o` file into an executable first, then analyze the executable.

unknown load address

Error message

unknown load address

What it means

Go object files (`.o` compiler output) are relocatable — they have no fixed load address because they are meant to be linked into a final binary. `goobjFile.loadAddress()` is a stub that always returns this error. Any caller that requests a load address from a `.o` file will get it, because the concept does not apply.

Source

Thrown at src/cmd/internal/objfile/goobj.go:337

		}
	}
	*p = s
	return v
}

// We treat the whole object file as the text section.
func (f *goobjFile) text() (textStart uint64, text []byte, err error) {
	text = make([]byte, f.goobj.Size)
	_, err = f.f.ReadAt(text, f.goobj.Offset)
	return
}

func (f *goobjFile) goarch() string {
	return f.goobj.Arch
}

func (f *goobjFile) loadAddress() (uint64, error) {
	return 0, fmt.Errorf("unknown load address")
}

func (f *goobjFile) dwarf() (*dwarf.Data, error) {
	return nil, errors.New("no DWARF data in go object file")
}

View on GitHub (pinned to b6b368adc5)

Solutions

Link the `.o` file into an executable first, then analyze the executable.
Check that you are pointing the tool at a linked binary: `file <path>` should say 'executable', not 'relocatable'.
Use `go tool nm` for symbol inspection of `.o` files, which does not require a load address.

Example fix

// before — analyzing a .o file
f, err := objfile.Open("main.o")
addr, err := f.LoadAddress()  // fails: no load address for .o

// after — link first, then analyze
$ go build -o main main.go
f, err := objfile.Open("main")
addr, err := f.LoadAddress()  // succeeds

Defensive patterns

Strategy: validation

Validate before calling

// Check if file is a linked executable, not a relocatable .o
func isExecutable(path string) bool {
    f, err := os.Open(path)
    if err != nil { return false }
    defer f.Close()
    buf := make([]byte, 18)
    f.Read(buf)
    // ELF executables have e_type=ET_EXEC (2) or ET_DYN (3)
    if bytes.HasPrefix(buf, []byte{0x7f, 'E', 'L', 'F'}) {
        return buf[16] == 2 || buf[16] == 3
    }
    // Mach-O, PE, etc. — use 'file' command as heuristic
    return true
}

Try / catch

addr, err := f.LoadAddress()
if err != nil && strings.Contains(err.Error(), "unknown load address") {
    if isGoObjectFile(path) {
        log.Printf("%s is a .o object file — link it first", path)
    }
}

Prevention

Link .o files into executables before running objfile-based tools.
Use 'file <path>' to confirm the file type before analysis.
Use 'go tool nm' for symbol inspection of .o files — it does not need a load address.

When it happens

Trigger: Calling `File.LoadAddress()` on a `.o` Go object file (as opposed to a linked executable). The `objfile` package tries all formats, and if the file is a Go object file, `loadAddress` will fail.

Common situations: Accidentally pointing a binary analysis tool (pprof, objdump) at a `.o` file instead of a linked executable. A build script passing intermediate object files to a tool that expects finished binaries.

Related errors

AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/3796c2016fcf55df. Report an issue: GitHub.