golang/go · error

unsupported architecture for SEH: %v

Error message

unsupported architecture for SEH: %v

What it means

The Go linker's Structured Exception Handling (SEH) processor was invoked for an architecture other than AMD64. SEH is the Windows exception handling mechanism; the Go linker processes `.pdata` sections from host object files to preserve exception handling metadata. Currently only the AMD64 (x86-64) architecture is implemented; calling `processSEH` on any other architecture family (ARM64, I386, etc.) returns this error.

Source

Thrown at src/cmd/link/internal/loadpe/seh.go:32

)

const (
	UNW_FLAG_EHANDLER  = 1 << 3
	UNW_FLAG_UHANDLER  = 2 << 3
	UNW_FLAG_CHAININFO = 4 << 3
	unwStaticDataSize  = 4 // Bytes of unwind data before the variable length part.
	unwCodeSize        = 2 // Bytes per unwind code.
)

// processSEH walks host-object pdata relocations and returns the set of
// per-entry pdata symbols created from the input section.
func processSEH(ldr *loader.Loader, arch *sys.Arch, pdata sym.LoaderSym) ([]loader.Sym, error) {
	switch arch.Family {
	case sys.AMD64:
		return processSEHAMD64(ldr, pdata)
	default:
		// TODO: support SEH on other architectures.
		return nil, fmt.Errorf("unsupported architecture for SEH: %v", arch.Family)
	}
}

func processSEHAMD64(ldr *loader.Loader, pdata sym.LoaderSym) ([]loader.Sym, error) {
	// The following loop traverses a list of pdata entries,
	// each entry being 3 relocations long. The first relocation
	// is a pointer to the function symbol to which the pdata entry
	// corresponds. The third relocation is a pointer to the
	// corresponding .xdata entry.
	// Reference:
	// https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-runtime_function
	rels := ldr.Relocs(pdata)
	if rels.Count()%3 != 0 {
		return nil, fmt.Errorf(".pdata symbol %q has invalid relocation count", ldr.SymName(pdata))
	}
	data := ldr.Data(pdata)
	entries := make([]loader.Sym, 0, rels.Count()/3)

View on GitHub (pinned to b6b368adc5)

Solutions

  1. Check if your target architecture is actually AMD64 — if you are cross-compiling, verify GOARCH is set correctly (`echo $GOARCH`).
  2. For Windows ARM64 cgo, use external linker mode (`-ldflags=-linkmode=external`) to delegate SEH processing to the system linker which handles all architectures.
  3. Update Go — ARM64 SEH support may be added in future releases; check the Go issue tracker and release notes.
  4. File a feature request / bug at https://go.dev/issue requesting SEH support for your target architecture.
  5. If possible, compile the C code without SEH unwind tables (e.g., `/SAFESEH:NO` with MSVC) to avoid triggering SEH processing.

Example fix

# Use external linker for non-AMD64 Windows targets
GOOS=windows GOARCH=arm64 go build -ldflags='-linkmode=external' ./...

# Or verify you are on the correct architecture
GOOS=windows GOARCH=amd64 go build ./...
Defensive patterns

Strategy: validation

Validate before calling

// Check target architecture before building with cgo on Windows
// For ARM64 Windows, use external linker mode:
if goarch == "arm64" && goos == "windows" {
    ldflags = append(ldflags, "-linkmode=external")
}

Prevention

When it happens

Trigger: Fires in `processSEH` at seh.go:26-33 when `arch.Family` does not match `sys.AMD64`. This function is called during PE object file loading when the linker encounters a `.pdata` section that needs SEH processing. The TODO comment confirms ARM64 and other Windows architectures are not yet supported.

Common situations: Cross-compiling Go with cgo for Windows ARM64 (`GOOS=windows GOARCH=arm64`) where the C object files contain .pdata sections. Linking ARM64 Windows object files that include SEH unwind data. Using an experimental or development version of Go on a new Windows architecture. Inadvertently triggering SEH processing on i386 Windows builds that include SEH-style object files.

Related errors

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