go-delve/delve · warning

interface type not yet supported by ebpf tracing

Error message

interface type not yet supported by ebpf tracing

What it means

When a traced argument resolves only to reflect.Interface via the eBPF UProbeArgMap and no DWARF type is available, synthesizeTypeFromKind marks the parameter Unreadable: an interface's dynamic type and value cannot be recovered from the raw register/stack bytes captured by the uprobe. The event still completes; this argument is just flagged unreadable.

Source

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

		iparam.Kind = reflect.Uintptr
		iparam.RealType = &godwarf.UintType{BasicType: godwarf.BasicType{CommonType: godwarf.CommonType{ByteSize: 8, ReflectKind: reflect.Uintptr}}}
	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

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Trace a concrete-typed wrapper function instead of the interface-typed entry point.
  2. Ensure the binary keeps full DWARF debug info so the argument's concrete DWARF type can be resolved upstream of synthesizeTypeFromKind.
  3. Handle Unreadable gracefully and display remaining arguments of the event.
  4. Check delve's eBPF supported-type list (int/uint/bool/float/complex/string/pointer/slice) before choosing arguments to trace.

Example fix

// before
dlv trace --ebpf logger.Log   // Log(msg string, err error)
// err param shows: interface type not yet supported by ebpf tracing
// after
// trace the concrete-typed variant:
func (l *Logger) LogErrString(s string) { l.Log(s, errors.New(s)) }
dlv trace --ebpf logger.LogErrString
Defensive patterns

Strategy: type-guard

Validate before calling

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

Type guard

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

Try / catch

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

Prevention

When it happens

Trigger: Tracing a function whose parameter is an interface type (e.g. error, io.Reader, any) through the eBPF backend when the DWARF type lookup failed or only the Kind was recorded, so handleParamEvent reaches 'case reflect.Interface'.

Common situations: 'dlv trace --ebpf' on functions accepting io.Writer/error/any parameters; tracing interface-heavy APIs; running with binaries lacking complete DWARF info.

Related errors

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