What causes "func type not yet supported by ebpf tracing" in go-delve/delve?

Avoid tracing functions whose parameters are func values; trace a wrapper with scalar/pointer arguments instead.

func type not yet supported by ebpf tracing

Error message

func type not yet supported by ebpf tracing

What it means

Func-typed arguments fall in the same unsupported branch set of synthesizeTypeFromKind: when only reflect.Func is known (no DWARF type), the parameter is marked Unreadable because a function value's code pointer/closure cannot be meaningfully reconstructed from the captured raw bytes. The trace event completes with this argument unreadable.

Source

Thrown at pkg/proc/internal/ebpf/helpers.go:571

	case reflect.String:
		if len(iparam.Data) >= 16 {
			iparam.Base = fakeAddressUnresolv + uint64(valSize)
			iparam.Len = int64(binary.LittleEndian.Uint64(iparam.Data[8:16]))
		}
		iparam.RealType = &godwarf.StringType{
			StructType: godwarf.StructType{
				CommonType: godwarf.CommonType{ByteSize: 16, ReflectKind: reflect.String},
				Kind:       "struct",
			},
		}
	case reflect.Map:
		iparam.Unreadable = fmt.Errorf("map type not yet supported by ebpf tracing")
	case reflect.Chan:
		iparam.Unreadable = fmt.Errorf("chan type not yet supported by ebpf tracing")
	case reflect.Interface:
		iparam.Unreadable = fmt.Errorf("interface type not yet supported by ebpf tracing")
	case reflect.Func:
		iparam.Unreadable = fmt.Errorf("func type not yet supported by ebpf tracing")
	case reflect.Struct:
		iparam.Unreadable = fmt.Errorf("struct type not yet supported by ebpf tracing without DWARF type")
	case reflect.Array:
		iparam.Unreadable = fmt.Errorf("array type not yet supported by ebpf tracing without DWARF type")
	default:
		iparam.Unreadable = fmt.Errorf("unrecognized reflect.Kind %d from eBPF", iparam.Kind)
	}
}

func createFunctionParameterList(entry uint64, goidOffset int64, args []UProbeArgMap, isret bool) function_parameter_list_t {
	var params function_parameter_list_t
	params.goid_offset = uint32(goidOffset)
	params.fn_addr = entry
	params.is_ret = isret
	params.n_parameters = 0
	params.n_ret_parameters = 0
	for _, arg := range args {
		var param function_parameter_t

View on GitHub (pinned to a23773e6c3)

Solutions

Avoid tracing functions whose parameters are func values; trace a wrapper with scalar/pointer arguments instead.
Keep full DWARF info in the target binary so the argument type is resolved before the Kind-only fallback.
Check and surface iparam.Unreadable in any tooling consuming GetBufferedTracepoints results.
Track delve eBPF type support; func/struct/array support requires DWARF types today.

Example fix

// before
dlv trace --ebpf scheduler.Run   // Run(task func(ctx context.Context) error)
// parameter shows: func type not yet supported by ebpf tracing
// after
// trace a named, concrete-typed entry point:
type TaskFn func(ctx context.Context) error
func (s *Scheduler) RunNamed(t TaskFn) { ... } // still unsupported; instead trace:
func (s *Scheduler) RunID(id int) { s.run(tasks[id]) }
dlv trace --ebpf scheduler.RunID

Defensive patterns

Strategy: type-guard

Validate before calling

// Detect func-typed parameters before tracing:
func hasFuncParam(types []godwarf.Type) bool {
	for _, t := range types {
		if t != nil && t.Common().ReflectKind == reflect.Func {
			return true
		}
	}
	return false
}

Type guard

func isFuncParam(p *RawUProbeParam) bool {
	return p != nil && p.Kind == reflect.Func
}

Try / catch

if p.Unreadable != nil && strings.Contains(p.Unreadable.Error(), "func type not yet supported") {
	fmt.Printf("param %s: <func value unavailable via eBPF>\n", p.Name)
	continue
}

Prevention

Avoid eBPF tracing of higher-order functions taking func values or method values.
Maintain full DWARF info in traced binaries so typed resolution is attempted.
Check Unreadable on parameters before value loading in any eBPF consumer.
Use regular breakpoints or a scalar-argument wrapper for callback-style APIs.

When it happens

Trigger: Tracing a function that takes a func value or method value as a parameter via the eBPF backend when the DWARF type is unavailable, causing handleParamEvent to fall back to synthesizeTypeFromKind and hit 'case reflect.Func'.

Common situations: 'dlv trace --ebpf' on callbacks-based APIs (e.g. http.HandlerFunc, sort.Slice less funcs); tracing higher-order functions; binaries with stripped or partial DWARF info.

Related errors

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