go-delve/delve · error

architecture not supported

Error message

architecture not supported

What it means

During binary info loading, Delve resolves architecture-specific TLS runtime symbols (runtime.tls_g and friends). pkg/proc/bininfo.go panics with "architecture not supported" when the ELF machine type is not one of the explicitly handled architectures (amd64, arm64, 386, arm, ppc64le, riscv64, loongarch in the switch). The comment states "we should never get here" — an internal invariant violation indicating an architecture reached symbol loading without being registered as supported.

Source

Thrown at pkg/proc/bininfo.go:1990

		// The TLS register points to the end of the TLS block, which is
		// tls.Memsz long. runtime.tlsg is an offset from the beginning of that block.
		bi.gStructOffset = ^(memsz) + 1 + tlsg.Value // -tls.Memsz + tlsg.Value

	case elf.EM_AARCH64:
		tlsg := getSymbol(image, bi.logger, exe, "runtime.tls_g")
		if tlsg == nil || tls == nil {
			bi.gStructOffset = 2 * uint64(bi.Arch.PtrSize())
			return
		}

		bi.gStructOffset = tlsg.Value + uint64(bi.Arch.PtrSize()*2) + ((tls.Vaddr - uint64(bi.Arch.PtrSize()*2)) & (tls.Align - 1))

	case elf.EM_PPC64, elf.EM_RISCV, elf.EM_LOONGARCH:
		_ = getSymbol(image, bi.logger, exe, "runtime.tls_g")

	default:
		// we should never get here
		panic("architecture not supported")
	}
}

func getSymbol(image *Image, logger logflags.Logger, exe *elf.File, name string) *elf.Symbol {
	symbols, err := exe.Symbols()
	if err != nil {
		image.setLoadError(logger, "could not parse ELF symbols: %v", err)
		return nil
	}

	for _, symbol := range symbols {
		if symbol.Name == name {
			s := symbol
			return &s
		}
	}
	return nil
}

View on GitHub (pinned to a23773e6c3)

Solutions

1. Debug a binary built for a supported architecture (amd64, arm64, 386, arm, ppc64le, riscv64, loongarch).
2. Verify the ELF header's e_machine field is valid; a corrupted header can hit the default branch.
3. Check Delve's version — newer releases add architectures; upgrade if your target was recently supported.
4. Check how the architecture was detected upstream (GOARCH/elf machine mapping in bininfo) if it should have been handled.

Example fix

// before
default:
	panic("architecture not supported")
// after
default:
	return fmt.Errorf("architecture %v not supported for TLS symbol resolution", exe.Machine)

// Go: check supported ELF machines before loading bininfo
var supported = map[elf.Machine]bool{
	elf.EM_X86_64: true, elf.EM_AARCH64: true, elf.EM_386: true, elf.EM_ARM: true,
	elf.EM_PPC64: true, elf.EM_RISCV: true, elf.EM_LOONGARCH: true,
}
if !supported[exe.Machine] {
	return fmt.Errorf("architecture %v not supported", exe.Machine)
}

When it happens

Trigger: Loading a binary whose elf.Machine falls in the default branch of the TLS symbol switch — i.e. a target architecture Delve does not support (s390x, mips, sparc, etc.) or a corrupted e_machine field.

Common situations: Attempting to debug binaries for unsupported architectures; corrupted ELF headers with a bogus e_machine value; custom/foreign toolchain outputs; misdetected binary format.

Related errors

• unsupported machine type
• reading NT_PRSTATUS: %v
• bad address size
• can't write halfway through a file
• not implemented

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/164ba3ec116cc394. Report an issue: GitHub.