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 calledView on GitHub (pinned to a23773e6c3)
Solutions
- Attach to or launch a live process with the native backend instead of examining a core dump
- Remove function calls from postmortem analysis workflows; use variable evaluation only
- 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
- Never use 'call' in core-dump analysis sessions
- Gate scripted 'call' commands on the session type (exec/attach, not core)
- Document backend capabilities in tooling that issues evaluations
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
- short read
- can not continue execution of core process
- can not change register values of core process
- unrecognized core format
- cannot write a breakpoint to a core file
AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31).
Data as JSON: /api/errors/3ec838f378cd800b.
Report an issue: GitHub.