mirror of
https://github.com/go-delve/delve.git
synced 2026-03-27 08:11:04 +01:00
0b686c36d0
* proc/internal/ebpf,build: extend eBPF tracing type support and update Docker build Add support for additional Go types in the eBPF tracing backend: - Bool: use BoolType with ByteSize 1 instead of IntType with ByteSize 8 - Int/Uint: use actual DWARF size instead of hardcoded ByteSize 8 - Float32/Float64: synthesize FloatType, detect XMM registers as unreadable - Complex64/Complex128: synthesize ComplexType with XMM detection - Pointer: capture pointer address and dereference pointed-to value via bpf_probe_read_user in eBPF C code - Slice: capture slice header (ptr+len+cap) and dereference element data - Graceful degradation: map, chan, interface, func, struct, and array types now produce specific "not yet supported" errors instead of generic "type not supported by ebpf" Add Unreadable field to RawUProbeParam so the Go-side parser can propagate specific error messages through to Variable display. Update eBPF build infrastructure: - Replace EOL Ubuntu 21.04 base image with Ubuntu 22.04 - Use clang-12 (required: newer clang generates BPF code that fails the kernel verifier with "dereference of modified ctx ptr disallowed") - Update Go from 1.17 to 1.24 - Remove sudo requirement from build-ebpf-builder-img.sh - Add -u flag to Docker run to avoid root-owned output files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * dwarf/godwarf,proc: fix slice ReflectKind and address PR review feedback Fix a bug in the DWARF type parser where SliceType.ReflectKind was not set (stayed 0/reflect.Invalid). When parsing struct types, the code creates a new StructType, sets ReflectKind on it, then for slices creates a new SliceType and reassigns the pointer — losing the ReflectKind. The String case already had an explicit fix for this (str.ReflectKind = reflect.String), but the Slice case was missing it. This caused the eBPF tracing backend (which uses dt.Common().ReflectKind to determine type kind) to see kind=0 for slice parameters, making them appear as unsupported types. The ptrace backend was unaffected because it uses Go type assertions (case *godwarf.SliceType) instead of ReflectKind. Also addresses PR review feedback: - Add t.Parallel() to TestTraceEBPFTypes subtests - Use regexp matching for pointer/slice address verification - Add content verification for slice test output - Add comment explaining -u flag in build-ebpf-objects.sh - Add comment explaining amd64-only XMM register threshold - Handle CreateCompositeMemory errors in target.go - Remove debug prints from target.go Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs: document eBPF type support pipeline and TestTraceEBPFTypes Add documentation for the eBPF type support pipeline, currently supported types, the canonical test (TestTraceEBPFTypes) for adding new type support, and the clang-12 build constraint. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * proc/internal/ebpf: clarify pointer/slice comments per review Clarify that the eBPF probe does capture dereferenced data, but loadValue runs Go-side after the probe returns and cannot follow pointer chains through fake memory addresses. Also remove unicode arrow from XMM register comment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * proc/internal/ebpf: clarify pointer/slice deref_val limitations Explain why we display raw addresses instead of dereferenced values: element type info isn't propagated through the eBPF pipeline, and deref_val is limited to 48 bytes which is insufficient for nested or variable-length types. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * address review feedback --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
/statusIcon.svg)
The GitHub issue tracker is for bugs only. Please use the developer mailing list for any feature proposals and discussions.
About Delve
Delve is a debugger for the Go programming language. The goal of the project is to provide a simple, full featured debugging tool for Go. Delve should be easy to invoke and easy to use. Chances are if you're using a debugger, things aren't going your way. With that in mind, Delve should stay out of your way as much as possible.