golang/go · error

no DWARF data in go object file

Error message

no DWARF data in go object file

What it means

Returned unconditionally by goobjFile.dwarf() in cmd/internal/objfile. gc object files do not embed DWARF debug info inside the goobj container the way some other formats do, so the objfile abstraction (used by cmd/pprof to locate cgo functions) reports that DWARF is simply not available for this file type. It is a permanent, by-design 'not supported' for the gc-object branch of the objfile backend.

Source

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

}

// 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

1. Point DWARF-consuming tooling at the linked executable or test binary, not the intermediate '.o' object file.
2. Build with DWARF enabled (-ldflags='-w' strips it; remove that flag) so the final binary carries debug info.
3. Treat this error as informational: detect it and fall back to gosym table-based symbolization instead of DWARF.
4. If you need DWARF from objects, switch to a backend (ELF/Mach-O/PE) via objfile's other file types.

Example fix

// before
entry, _ := objfile.Open(objPath)
data, err := entry.DWARF() // err == "no DWARF data in go object file"

// after: operate on the final binary
entry, _ := objfile.Open(binPath) // linked executable
data, err := entry.DWARF()

// Skip DWARF() for goobj-backed entries; it never succeeds.
func supportsDWARF(e *objfile.Entry) bool {
    // heuristic: gc objects never carry DWARF via this API
    return false // for goobj-backed entries
}

func isNoDWARF(err error) bool {
    return err != nil && strings.Contains(err.Error(), "no DWARF data")
}

data, err := entry.DWARF()
if err != nil {
    if strings.Contains(err.Error(), "no DWARF data") {
        // fall back to gosym table; not fatal
        return symTableOnly(entry)
    }
    return err
}

When it happens

Trigger: Calling (*objfile.Entry).DWARF() (objfile.go:178) on an Entry whose raw file is a gc goobj file. The dispatch reaches goobjFile.dwarf() which always returns this error. pprof or any DWARF-consuming tool hitting a '.o' produced by gc will trigger it.

Common situations: A pprof / symbol-resolution workflow pointed at an intermediate gc object file rather than the final linked executable (which does carry DWARF). Mistaking the gc object for an ELF/Mach-O binary that pprof can read.

Related errors

• no DWARF data in Plan 9 file
• subprogram DIE high not convertible to uint64
• subprogram DIE high_pc not convertible to uint64
• subprogram DIE high_pc unknown value class %s
• multiple toplevel scopes

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