go-delve/delve · error

not implemented

Error message

not implemented

What it means

Delve needs to reconstruct the register state saved by the Windows signal trampoline (runtime.sigtrampgo) so it can continue unwinding the stack across a signal handler frame. This reconstruction is only implemented for the windows/amd64 and windows/arm64 combinations; any other architecture hits the switch default in readSigtrampgoContext and returns the bare 'not implemented' error. It is a deliberate feature gap, not a bug in the debugged program.

Source

Thrown at pkg/proc/stack_sigtramp.go:70

	}

	switch bi.GOOS {
	case "windows":
		epvar := findvar("ep")
		if epvar == nil {
			return nil, errors.New("ep variable not found")
		}
		epaddr, err := deref(epvar)
		if err != nil {
			return nil, err
		}
		switch bi.Arch.Name {
		case "amd64":
			return sigtrampContextWindowsAMD64(it.mem, epaddr)
		case "arm64":
			return sigtrampContextWindowsARM64(it.mem, epaddr)
		default:
			return nil, errors.New("not implemented")
		}
	case "linux":
		addr, err := getctxaddr()
		if err != nil {
			return nil, err
		}

		switch bi.Arch.Name {
		case "386":
			return sigtrampContextLinux386(it.mem, addr)
		case "amd64":
			return sigtrampContextLinuxAMD64(it.mem, addr)
		case "arm64":
			return sigtrampContextLinuxARM64(it.mem, addr)
		case "loong64":
			return sigtrampContextLinuxLOONG64(it.mem, addr)
		case "riscv64":
			return sigtrampContextLinuxRISCV64(it.mem, addr)

View on GitHub (pinned to a23773e6c3)

Solutions

1. Check the debugged binary's GOOS/GOARCH; rebuild it for windows/amd64 or windows/arm64, which are the only supported combinations for signal-frame unwinding on Windows
2. Upgrade Delve to the latest version in case support for your architecture was added after your build
3. If the arch cannot be changed, avoid stepping into/unwinding through signal-handling code paths (cgo/panic paths that go through sigtrampgo) and inspect the program state before the signal
4. File/track an upstream go-delve/delve issue requesting sigtrampgo support for your architecture

Example fix

// before: debugging a windows/386 binary
GOOS=windows GOARCH=386 go build -gcflags="all=-N -l" -o app.exe
// after: rebuild for a supported arch
GOOS=windows GOARCH=amd64 go build -gcflags="all=-N -l" -o app.exe

// before starting the debug session, verify a supported Windows arch
bi := getBinaryInfo(path) // via your tooling
if bi.GOOS == "windows" && bi.Arch != "amd64" && bi.Arch != "arm64" {
    return fmt.Errorf("sigtramp stepping unsupported on windows/%s; rebuild for amd64 or arm64", bi.Arch)
}

func windowsArchSupported(arch string) bool {
    return arch == "amd64" || arch == "arm64"
}

// wrap stepping calls
if err := dlvClient.Next(...); err != nil {
    if strings.Contains(err.Error(), "not implemented") && goos == "windows" {
        // fall back to breakpoint-based stepping instead of stepping through the signal frame
        return fallbackStepWithBreakpoints()
    }
    return err
}

When it happens

Trigger: Debugging a Windows target where the stack iterator crosses a sigtrampgo frame while the binary is built for an architecture other than amd64 or arm64 (e.g. windows/386), during stepping operations such as Next that must unwind through a signal handler.

Common situations: Running Delve on a Windows host debugging a Go program built for an unsupported Windows architecture; using an ARM Windows device with an x86 or 386 Go binary; Delve releases from before the desired arch's sigtramp reader was added.

Related errors

• corrupted stack (SP not monotonically decreasing)
• could not find range-over-func closure parent on the stack
• incomplete range-over-func stacktrace
• ep variable not found
• could not dereference %s: %v

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