Gobee: write eBPF programs in Go, transpiled via clang
Summary
Gobee is a tool that transpiles a subset of Go into BPF C, allowing developers to write eBPF programs in Go instead of C. It generates typed Go bindings for userspace and uses clang's backend for compilation.
View Cached Full Text
Cached at: 05/21/26, 06:17 PM
boratanrikulu/gobee
Source: https://github.com/boratanrikulu/gobee
gobee
Write your BPF programs in Go, not C. gobee transpiles a strict subset of Go into BPF C, generates typed Go bindings for the userspace side, and gates loads against the running kernel.
The Go ecosystem has solid userspace tooling for BPF. The kernel side has always ended with “now write your program in C.” Aya brought eBPF to Rust by writing a new BPF backend in rustc. gobee gets there a different way: by transpiling to C and reusing clang’s mature backend.
A Go file in, a BPF program out
A tracepoint that streams every execve to userspace via a ringbuf:
| Your input (Go) | What gobee emits (BPF C) |
|---|---|
|
|
gobee translate --bindings-dir ./bpf ./bpf/src produces both files, plus a sourcemap (events.bpf.c.map) so verifier errors map back to Go lines and a typed bindings file (bpf/events_bindings.go) so the userspace driver writes objs.Events, objs.AttachOnExec(), and decodes ringbuf payloads straight into bpf.Event (the same struct you see above, re-published in Go) instead of stringly-typed coll.Programs["..."] lookups.
The C is readable on purpose. If gobee emits something weird, you can see it. For tracepoints + kprobes + XDP combined into one binary, see example/sysmon/.
How it compares
| gobee | C + clang + bpf2go | Aya (Rust) | bpftrace | BCC | |
|---|---|---|---|---|---|
| Kernel-side language | Go subset | C | Rust | DSL | C |
| Userspace integration | typed Go bindings + cilium/ebpf | bpf2go | aya-runtime | none | python |
| CO-RE | ✅ via clang | ✅ | ✅ via LLVM | ✅ | ✅ |
| Helper coverage | 200 typed Go wrappers | full (write C) | full | limited | full (write C) |
| Verifier error → source | ✅ Go file:line:col | ❌ raw C | ✅ Rust file:line | ❌ | partial |
| Kernel-version gate at load | ✅ via bpfvet | manual | manual | n/a | runtime |
| Toolchain deps | Go + clang | clang + bpf2go | rustc + LLVM | bpftrace | python + bcc |
| Generated artifact | .bpf.o + Go binary | .bpf.o + Go binary | .bpf.o + Rust binary | JIT | JIT |
If you’re already in a C / libbpf workflow, gobee is not trying to replace it wholesale. It’s for cases where you want the kernel side, the userspace side, and the build pipeline all in one Go module.
What’s supported today
See docs/status.md for the full matrix (Go subset, statements, expressions, every helper, every map type, every directive). Quick view:
| Surface | Coverage |
|---|---|
| Program types (8) | XDP, tracepoint, kprobe / kretprobe, uprobe / uretprobe, sock_ops, TC, cgroup_skb, LSM |
| Map types (19) | array, hash, lru_hash, per-CPU variants, bloom_filter, lpm_trie, ringbuf, perf_event_array, prog_array, queue, stack, sk/task/inode storage, devmap/cpumap/xskmap |
| BPF helpers | ~200 typed Go stubs auto-generated from libbpf v1.5.0 headers. The ones exercised by example/helloworld/ and example/sysmon/ are tested in real-kernel CI; the rest are unverified. File an issue if a stub doesn’t match the kernel signature |
| CO-RE | ✅ auto-detected. BPF_CORE_READ for kernel-internal struct fields (task_struct, sock, inode); direct ctx->field for UAPI BPF context structs (xdp_md, __sk_buff, bpf_sock_ops). Exercised on Linux 6.x (Ubuntu 24.04 CI); older kernels not yet in the CI matrix |
| BTF-ready output | ✅ emitted C includes vmlinux.h and uses BPF_CORE_READ for kernel-internal field reads, so the BTF clang generates from clang -g carries the right relocations. clang itself stays your responsibility (the example Makefiles show the canonical invocation) |
| User-defined helpers | ✅ top-level Go funcs without //bpf:section are emitted as static __always_inline C functions |
| Typed Go bindings | ✅ Load<Stem>, Close, per-program Attach<Name>, AttachAll, plus your kernel-side struct types and constants re-published in Go |
| Kernel-version gate | ✅ bpfvet runs at load time. Fails fast with bpf program needs kernel >= 5.8, host is 5.4 instead of opaque EINVAL |
| Verifier error → Go source | ✅ auto-annotated inside Load<Stem>. No manual pipe to gobee diagnose; *ebpf.VerifierError comes back with → counter.go:18:5 markers |
| Sourcemap sidecar | ✅ <stem>.bpf.c.map written next to every .bpf.c for offline gobee diagnose use too |
| Cross-arch | ✅ Linux arm64 + amd64 |
What gobee does
- Transpiles a Go subset to BPF C (and runs
go/typesover your input first, so misuses surface atfile:line:col). - Generates a typed
<Stem>_bindings.gonext to the.bpf.c:bpf.LoadCounter(spec),objs.PerIface.Lookup(...),objs.AttachAll(ifindex), plus your kernel-side struct types and constants re-published in Go. - Auto-annotates
*ebpf.VerifierErrorfromLoadAndAssignwith Go source positions, no manualgobee diagnosepipe needed. - Runs bpfvet inside
Load<Stem>so old kernels fail fast withbpf program needs kernel >= 5.8, host is 5.4. - Surfaces ~200 typed Go stubs for the libbpf v1.5.0 helper set, plus user-defined helper functions emitted as
static __always_inline.
What gobee won’t do
- Replace clang. clang’s BPF backend gives us CO-RE, BTF, and verifier-friendly codegen for free. Reimplementing that costs years and gains nothing.
- Replace
cilium/ebpf. The generated bindings sit on top of it. - Hide BPF. The Go subset maps 1:1 to BPF C idioms. If you know BPF, gobee is thin sugar. If you don’t, the manual is still required reading.
- Run clang for you. Compile, embed, and load remain user-owned. Same pattern as bpf2go.
Why transpile, not generate BPF directly
gc, the Go compiler, has no LLVM-based BPF backend. Adding one is a multi-year compiler project. rustc is built on LLVM and that’s why Aya works. So gobee emits C and reuses clang’s BPF backend, which gives us mature codegen, BTF, and CO-RE relocations for free.
Quickstart
go install github.com/boratanrikulu/gobee/cmd/gobee@latest
cd example/helloworld
make build # gobee translate, clang, go build
sudo ./helloworld eth0
You’ll need clang with the BPF target. On Linux that’s the distro package; on macOS, brew install llvm. The transpiler itself is pure Go and runs anywhere.
Project layout (typical)
yourproject/
├── bpf/ # Go package, importable from anywhere in your project
│ ├── embed_amd64.go # //go:embed bin/x86/your.bpf.o
│ ├── embed_arm64.go
│ ├── your_bindings.go # generated by gobee
│ ├── bin/{x86,arm64}/your.bpf.o
│ └── src/ # not a Go package; clang lives here
│ ├── your.go # //go:build ignore: BPF source
│ ├── your.bpf.c # generated
│ ├── Makefile # clang per arch
│ └── vmlinux.h # vendored BTF dump
├── main.go # imports yourproject/bpf
└── Makefile
The split keeps bpf/ a clean importable Go package (Go rejects .c files in non-cgo packages). Kernel sources and clang artifacts live one level down in bpf/src/.
Examples
example/helloworld/: the canonical XDP packet counter, ~40 lines BPF, ~80 lines userspace.example/sysmon/: XDP, two tracepoints, and a kprobe in one binary, sharing a ringbuf for events. Demonstrates per-syscall typed contexts, user-defined helper functions, and theAttachAllshortcut.
CI
GitHub Actions runs four layers on every push:
go test,go vet, transpiler golden tests- Coverage matrix: every map type and
//bpf:sectionkind has at least one example - clang compile of every curated example, then
bpfvetportability report - Real-kernel verifier acceptance:
ebpf.NewCollectionWithOptionson each.bpf.o(Ubuntu 24.04 runner, kernel 6.x)
Docs
docs/design.md: architecture and rationaledocs/go-subset.md: accepted Go syntax in BPF source filesdocs/directives.md://bpf:*referencedocs/status.md: support matrix (single source of truth)
Toolchain
- The gobee binary builds anywhere (pure Go, no CGO).
- Compiling
.bpf.oneeds clang with the BPF target. Apple’s bundled clang doesn’t ship with it; on macOS usebrew install llvmor build inside a Linux VM. - Running the artifact needs Linux on arm64 or amd64.
Inspirations
- Solod: the Go-to-C transpiler that proved this pattern works.
- Aya: the Rust eBPF framework whose ergonomics gobee chases.
License
MIT. See LICENSE.
Copyright (c) 2026 Bora Tanrikulu <[email protected]>
Similar Articles
BPF support in GCC 16 and beyond
José Marchesi and the GCC-BPF team provided an update on BPF support in GCC 16, highlighting progress toward feature parity with LLVM and increasing pass rate of the kernel's BPF self-tests.
The Go language server can do some impressive code navigation
The Go language server (gopls) offers impressive code navigation features for Go developers, enhancing IDE capabilities.
QBE – Compiler Back End
QBE is a compact, hobby-scale compiler backend that provides 70% of the performance of industrial optimizing compilers in 10% of the code, supporting amd64, arm64, and riscv64 with a simple SSA-based intermediate language.
Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE
Blaise is a modern, self-hosting Object Pascal compiler designed to eliminate legacy baggage by offering a single language mode, unified memory model, and native code generation via QBE.
Notes from Optimizing CPU-Bound Go Hot Paths
The article discusses performance optimization techniques for CPU-bound Go code, highlighting the limitations of generics and interface abstractions due to lack of inlining, and advocates for code duplication in hot paths. It provides examples from a Brotli port and deep-dive benchmarking.