golang/go · warning

unknown load address

Error message

unknown load address

What it means

When analyzing an ELF binary, `elfFile.loadAddress()` scans all program headers (PT_LOAD segments) looking for one with the executable flag (PF_X) to determine the base virtual address. If no executable PT_LOAD segment is found, this error is returned. The load address is needed by tools like pprof to compute PC deltas from memory mappings.

Solutions

1. Verify the file is an ELF executable with at least one executable PT_LOAD segment: `readelf -l <file> | grep LOAD`.
2. Ensure the binary was linked normally (not `-nostdlib` or custom linker scripts that remove exec segments).
3. If analyzing a library or object, use the appropriate analysis path rather than expecting a load address.
4. Rebuild the binary with standard linking options.

Example fix

// before — analyzing a .so with no exec PT_LOAD segment
f, _ := objfile.Open("libfoo.so")
addr, err := f.LoadAddress()  // fails

// after — analyze a linked executable
f, _ := objfile.Open("main_executable")
addr, err := f.LoadAddress()  // succeeds

// Check for executable PT_LOAD segment
func hasExecutableLoadSegment(path string) bool {
    f, err := elf.Open(path)
    if err != nil { return false }
    defer f.Close()
    for _, p := range f.Progs {
        if p.Type == elf.PT_LOAD && p.Flags&elf.PF_X != 0 {
            return true
        }
    }
    return false
}

addr, err := f.LoadAddress()
if err != nil && strings.Contains(err.Error(), "unknown load address") {
    // Non-executable ELF; use 0 or infer from section addresses
    addr = 0
} else if err != nil {
    return err
}

When it happens

Trigger: Calling `objfile.Open` followed by `File.LoadAddress()` on an ELF binary whose program headers contain no PT_LOAD segment with the PF_X (execute) flag. This happens with non-executable ELF files (shared libraries without exec segments, data-only ELFs, or kernel modules) or binaries produced by unusual linkers.

Common situations: Analyzing a shared library (`.so`) or a relocatable object that has no executable segment at the program-header level. Using pprof against a binary produced by a non-standard build process. Examining an ELF file that is not a normal Go executable.

Related errors

• text section not found
• unknown load address
• .ARM.attributes has unexpected format %c
• cannot find .go.fipsinfo
• corrupt .ARM.attributes (section name not NUL-terminated)

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

Appendix: source

Thrown at src/cmd/internal/objfile/elf.go:141

		}
	case elf.EM_S390:
		return "s390x"
	}
	return ""
}

func (f *elfFile) loadAddress() (uint64, error) {
	for _, p := range f.elf.Progs {
		if p.Type == elf.PT_LOAD && p.Flags&elf.PF_X != 0 {
			// The memory mapping that contains the segment
			// starts at an aligned address. Apparently this
			// is what pprof expects, as it uses this and the
			// start address of the mapping to compute PC
			// delta.
			return p.Vaddr - p.Vaddr%p.Align, nil
		}
	}
	return 0, fmt.Errorf("unknown load address")
}

func (f *elfFile) dwarf() (*dwarf.Data, error) {
	return f.elf.DWARF()
}

func (f *elfFile) symbolData(start, end string) []byte {
	elfSyms, err := f.elf.Symbols()
	if err != nil {
		return nil
	}
	var addr, eaddr uint64
	for _, s := range elfSyms {
		if s.Name == start {
			addr = s.Value
		} else if s.Name == end {
			eaddr = s.Value
		}

View on GitHub (pinned to b6b368adc5)