go-delve/delve · error

backend does not support function calls

Error message

backend does not support function calls

What it means

errFuncCallUnsupportedBackend indicates the selected debugging backend (e.g. core dump analysis, or a backend lacking the required primitives) cannot perform function-call injection, independent of the Go version. Returned by EvalExpressionWithCalls and evalCallInjectionStart in pkg/proc/fncall.go.

Source

Thrown at pkg/proc/fncall.go:60

//
//  - evalop.CallInjectionStart
//  - evalop.CallInjectionSetTarget
//  - evalCallInjectionCopyArg
//  - evalCallInjectionComplete
//
// When the target has runtime.debugPinner then evalCallInjectionPinPointer
// must be also called in a loop until it returns false.

const (
	debugCallFunctionNamePrefix1 = "debugCall"
	debugCallFunctionNamePrefix2 = "runtime.debugCall"
	maxDebugCallVersion          = 2
	maxArgFrameSize              = 65535
)

var (
	errFuncCallUnsupported        = errors.New("function calls not supported by this version of Go")
	errFuncCallUnsupportedBackend = errors.New("backend does not support function calls")
	errFuncCallInProgress         = errors.New("cannot call function while another function call is already in progress")
	errNoGoroutine                = errors.New("no goroutine selected")
	errGoroutineNotRunning        = errors.New("selected goroutine not running")
	errNotEnoughStack             = errors.New("not enough stack space")
	errTooManyArguments           = errors.New("too many arguments")
	errNotEnoughArguments         = errors.New("not enough arguments")
	errNotAGoFunction             = errors.New("not a Go function")
	errFuncCallNotAllowedStrAlloc = errors.New("literal string can not be allocated because function calls are not allowed without using 'call'")
)

type functionCallState struct {
	// savedRegs contains the saved registers
	savedRegs Registers
	// err contains a saved error
	err error
	// expr is the expression being evaluated
	expr *ast.CallExpr
	// fn is the function that is being called

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Attach to or launch a live process with the native backend instead of examining a core dump
  2. Remove function calls from postmortem analysis workflows; use variable evaluation only
  3. Check backend capabilities before scripting 'call' commands

Example fix

// before
dlv core ./app core.dump
dlv> call foo(1)
// after
dlv exec ./app
dlv> call foo(1)
Defensive patterns

Strategy: validation

Validate before calling

// only issue function calls on a live native process, never against core dumps
// dlv exec ./app  (good)   vs   dlv core ./app core (no calls)

Try / catch

if errors.Is(err, proc.ErrFuncCallUnsupportedBackend) {
    // switch to live-process debugging or drop the call from the workflow
}

Prevention

When it happens

Trigger: Requesting a function call while debugging a core dump (pkg/proc/core) or through a backend that has not implemented call injection; the 'call' command in a session that is not attached to a live native process.

Common situations: Trying 'call' while analyzing a core dump; remote/gdbserial sessions without call support; scripts that run the same eval set against both live and postmortem targets.

Related errors


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