golang/go · info

unknown load address

Error message

unknown load address

What it means

xcoffFile.loadAddress() unconditionally returns 'unknown load address'. The XCOFF backend does not recover a fixed image base the way PE/ELF do, so it declines rather than fabricate one. Callers needing a base should use textStart from text().

Source

Thrown at src/cmd/internal/objfile/xcoff.go:157

	data, err := sect.Data()
	if err != nil {
		return nil, err
	}
	return data[ssym.Value:esym.Value], nil
}

func (f *xcoffFile) goarch() string {
	switch f.xcoff.TargetMachine {
	case xcoff.U802TOCMAGIC:
		return "ppc"
	case xcoff.U64_TOCMAGIC:
		return "ppc64"
	}
	return ""
}

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

func (f *xcoffFile) dwarf() (*dwarf.Data, error) {
	return f.xcoff.DWARF()
}

View on GitHub (pinned to b6b368adc5)

Solutions

1. Do not rely on loadAddress for XCOFF; use the textStart returned from text().
2. Treat this specific error as non-fatal in the caller.

// XCOFF has no recoverable load address; detect the backend and skip loadAddress.
// switch pf.(type) {
// case *xcoffFile:
//     // use textStart from text() instead
// default:
//     base, err = pf.loadAddress()
// }

// base, err := pf.loadAddress()
// if err != nil && err.Error() == "unknown load address" {
//     // expected for xcoff; fall back to textStart
// }

When it happens

Trigger: Any call to xcoffFile.loadAddress() — a permanent limitation of the XCOFF backend, not a transient failure.

Common situations: A tool that uniformly calls loadAddress across backends will always hit this for XCOFF binaries. Expected behavior.

Related errors

• unknown load address
• invalid section number in symbol table
• text section not found
• symbol %s: invalid section number %d
• symbol %s: section number %d is larger than max %d

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