GPTtrace

GPTtrace occupies an unusual spot: it is a natural-language front-end to eBPF, but the eunomia community has deliberately kept it narrow, research-flavoured, and honest about what it can't promise. What it actually does. You give it a tracing request in plain English and it drafts eBPF source. The project covers kprobes, tracepoints, and other program types, and pairs with eunomia-bpf for CO-RE, so the compiled program is not tied to the kernel you generated it on. Interaction is CLI-only. The eunomia team frames GPTtrace alongside MCPtrace as their 'using LLM to help you trace your kernel' projects, and credits ChatGPT as the LLM backend. Where the verification story lives. The paper project Kgent incorporates Z3-based symbolic checks and tests to produce more reliable code, achieving roughly 80% semantic correctness on its test sets. Read that carefully: 80% is measured by a companion research project, on its own test sets, and the check is not automatic when you run GPTtrace. One program in five may not mean what you intended. That is the single most important number on this page. Strengths. It is free and open source, so the downside is mostly your review time rather than a licence. It sits inside a genuine ecosystem rather than standing alone — bpftime (eBPF bytecode offloaded to GPUs via PTX/SPIR-V injection, merged into bpftime's main branch), wasm-bpf, AgentSight for tracing LLM and AI agent activity via eBPF TLS interception with under 3% overhead, and SchedCP. If you want to see where LLM-assisted kernel tracing is heading, this is the community doing the work. Weaknesses. Generated programs may contain errors or inefficiencies and need manual verification. Correctness depends on ChatGPT's grasp of eBPF and kernel internals, which is inconsistent for complex cases. There is no web or GUI interface — this is a terminal tool for people comfortable in one. And the value is squarely a function of what you already know: if you can't read a kprobe and tell whether the helper call is right, the draft is not much use to you. Where it fits. Prototyping when you know the kernel hook point you want but not the exact helper syntax. Learning eBPF by reading generated kprobe and tracepoint code before hand-editing it. Counting TCP connections per second, tracing file-open events at syscall entry, watching context switches for noisy neighbours, or drafting probes against GPU driver functions to measure kernel launch latencies. Where it doesn't. Anywhere you need an unreviewed program to be correct. Teams that require battle-tested instrumentation without a review step should stay with hand-written eBPF or a commercial agent. Developers who want a visual builder will find nothing here. And beginners unfamiliar with kernel concepts will struggle to tell a good draft from a bad one.