could not map %s symbol with non .text or .rdata or .data se

Error message

could not map %s symbol with non .text or .rdata or .data section

What it means

`mapToPESection` only knows how to map symbols whose section belongs to `Segtext`, `Segrodata`, or `Segdata`. If a symbol's section has a `Seg` pointer that is not one of these three (e.g. a TLS section, an exception/unwind-data section like `.pdata`/`.xdata`, or a runtime internal pseudo-segment), the linker cannot compute a PE offset and aborts. This is almost always an internal bug or a non-standard section reaching the PE symbol emitter.

Source

Thrown at src/cmd/link/internal/ld/pe.go:859

	f.symbolCount++
}

// mapToPESection searches peFile f for s symbol's location.
// It returns PE section index, and offset within that section.
func (f *peFile) mapToPESection(ldr *loader.Loader, s loader.Sym, linkmode LinkMode) (pesectidx int, offset int64, err error) {
	sect := ldr.SymSect(s)
	if sect == nil {
		return 0, 0, fmt.Errorf("could not map %s symbol with no section", ldr.SymName(s))
	}
	if sect.Seg == &Segtext {
		return f.textSect.index, int64(uint64(ldr.SymValue(s)) - Segtext.Vaddr), nil
	}
	if sect.Seg == &Segrodata {
		return f.rdataSect.index, int64(uint64(ldr.SymValue(s)) - Segrodata.Vaddr), nil
	}
	if sect.Seg != &Segdata {
		return 0, 0, fmt.Errorf("could not map %s symbol with non .text or .rdata or .data section", ldr.SymName(s))
	}
	v := uint64(ldr.SymValue(s)) - Segdata.Vaddr
	if linkmode != LinkExternal {
		return f.dataSect.index, int64(v), nil
	}
	if ldr.SymType(s).IsDATA() {
		return f.dataSect.index, int64(v), nil
	}
	// Note: although address of runtime.edata (type sym.SDATA) is at the start of .bss section
	// it still belongs to the .data section, not the .bss section.
	if v < Segdata.Filelen {
		return f.dataSect.index, int64(v), nil
	}
	return f.bssSect.index, int64(v - Segdata.Filelen), nil
}

var isLabel = make(map[loader.Sym]bool)

View on GitHub (pinned to b6b368adc5)

Solutions

Upgrade the Go toolchain — PE section mapping has been extended in recent releases.
Rebuild with `go build -a` to rule out cache inconsistency.
Avoid exporting the offending symbol, or ensure it lands in a standard segment (move TLS to a Go-managed variable).
File a Go issue with the symbol name and section, as this usually reflects an unmapped section type.

Defensive patterns

Strategy: fallback

Validate before calling

# Identify symbols in non-standard PE sections (TLS, pdata, rsrc)
go tool nm bin/app 2>/dev/null | awk '{print $NF}' | sort -u
# Symbols landing in .tls/.pdata/.rsrc trigger this error during export

Try / catch

set +e
go build ./...
rc=$?
set -e
if [ $rc -ne 0 ]; then
  echo 'PE section mapping failed; upgrade Go or avoid exporting the symbol' >&2
  go clean -cache && go build -a ./...
fi

Prevention

Upgrade the Go toolchain — PE section coverage has expanded.
Avoid exporting cgo symbols that live in TLS or exception-data sections.
Move Windows TLS state into Go-managed variables.
Rebuild with `-a` after toolchain changes.

When it happens

Trigger: A cgo symbol landing in `.tls`, `.pdata`, or `.rsrc`; an internal-linker symbol whose section was misclassified; building with experimental flags that introduce new segments; toolchain version skew between compiled objects.

Common situations: Windows cgo with thread-local storage; exporting a symbol that the compiler placed in an auxiliary data section; older Go versions with PE section-mapping gaps.

Related errors

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