[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-78142":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":32,"readmeContent":33,"aiSummary":34,"trendingCount":15,"starSnapshotCount":15,"syncStatus":14,"lastSyncTime":35,"discoverSource":36},78142,"gobee","boratanrikulu\u002Fgobee","boratanrikulu","Write your BPF programs in Go, not C. gobee transpiles a Go subset to BPF C and generates typed cilium\u002Febpf bindings.","",null,"Go",327,4,2,0,5,31,284,15,2.1,"MIT License",false,"main",[25,26,27,28,29,30,31],"bpf","cilium-ebpf","ebpf","golang","kernel","linux","transpiler","2026-06-12 02:03:46","# gobee\n\n**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.\n\nThe 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.\n\n## A Go file in, a BPF program out\n\nA tracepoint that streams every `execve` to userspace via a ringbuf:\n\n\u003Ctable>\n\u003Ctr>\n\u003Cth>Your input (Go)\u003C\u002Fth>\n\u003Cth>What gobee emits (BPF C)\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\n\n```go\n\u002F\u002Fgo:build ignore\n\npackage main\n\nimport \"github.com\u002Fboratanrikulu\u002Fgobee\u002Fbpf\"\n\n\u002F\u002Fbpf:license GPL\n\ntype Event struct {\n    Pid  uint32\n    Comm [16]byte\n}\n\nvar Events = bpf.RingBuf[Event]{\n    MaxEntries: 4096,\n}\n\n\u002F\u002Fbpf:section tracepoint\u002Fsyscalls\u002Fsys_enter_execve\nfunc OnExec(ctx *bpf.ExecveEnterCtx) bpf.TpReturn {\n    e, ok := Events.Reserve()\n    if !ok {\n        return bpf.TpOk\n    }\n    e.Pid = bpf.GetCurrentPid()\n    bpf.GetTaskComm(&e.Comm)\n    Events.Submit(e)\n    return bpf.TpOk\n}\n\nfunc main() {}\n```\n\n\u003C\u002Ftd>\n\u003Ctd>\n\n```c\n\u002F\u002F Code generated by gobee. DO NOT EDIT.\n\n#include \"vmlinux.h\"\n#include \u003Cbpf\u002Fbpf_helpers.h>\n#include \u003Cbpf\u002Fbpf_core_read.h>\n\nchar _license[] SEC(\"license\") = \"GPL\";\n\nstruct Event {\n    __u32 Pid;\n    __u8 Comm[16];\n};\n\nstruct {\n    __uint(type, BPF_MAP_TYPE_RINGBUF);\n    __uint(max_entries, 4096);\n} Events SEC(\".maps\");\n\nSEC(\"tracepoint\u002Fsyscalls\u002Fsys_enter_execve\")\nint OnExec(struct trace_event_raw_sys_enter *ctx) {\n    struct Event *e = bpf_ringbuf_reserve(\n        &Events, sizeof(struct Event), 0);\n    if (!e) {\n        return 0;\n    }\n    e->Pid = (__u32)(\n        bpf_get_current_pid_tgid() >> 32);\n    bpf_get_current_comm(&e->Comm, 16);\n    bpf_ringbuf_submit(e, 0);\n    return 0;\n}\n```\n\n\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftable>\n\n`gobee translate --bindings-dir .\u002Fbpf .\u002Fbpf\u002Fsrc` produces both files, plus a sourcemap (`events.bpf.c.map`) so verifier errors map back to Go lines and a typed bindings file (`bpf\u002Fevents_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.\n\nThe C is readable on purpose. If gobee emits something weird, you can see it. For tracepoints + kprobes + XDP combined into one binary, see [`example\u002Fsysmon\u002F`](example\u002Fsysmon\u002F).\n\n## How it compares\n\n| | gobee | C + clang + bpf2go | Aya (Rust) | bpftrace | BCC |\n|---|---|---|---|---|---|\n| Kernel-side language | Go subset | C | Rust | DSL | C |\n| Userspace integration | typed Go bindings + cilium\u002Febpf | bpf2go | aya-runtime | none | python |\n| CO-RE | ✅ via clang | ✅ | ✅ via LLVM | ✅ | ✅ |\n| Helper coverage | 200 typed Go wrappers | full (write C) | full | limited | full (write C) |\n| Verifier error → source | ✅ Go file:line:col | ❌ raw C | ✅ Rust file:line | ❌ | partial |\n| Kernel-version gate at load | ✅ via bpfvet | manual | manual | n\u002Fa | runtime |\n| Toolchain deps | Go + clang | clang + bpf2go | rustc + LLVM | bpftrace | python + bcc |\n| Generated artifact | `.bpf.o` + Go binary | `.bpf.o` + Go binary | `.bpf.o` + Rust binary | JIT | JIT |\n\nIf you're already in a C \u002F 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.\n\n## What's supported today\n\nSee [`docs\u002Fstatus.md`](docs\u002Fstatus.md) for the full matrix (Go subset, statements, expressions, every helper, every map type, every directive). Quick view:\n\n| Surface | Coverage |\n|---|---|\n| **Program types** (8) | XDP, tracepoint, kprobe \u002F kretprobe, uprobe \u002F uretprobe, sock_ops, TC, cgroup_skb, LSM |\n| **Map types** (19) | `array`, `hash`, `lru_hash`, per-CPU variants, `bloom_filter`, `lpm_trie`, `ringbuf`, `perf_event_array`, `prog_array`, `queue`, `stack`, sk\u002Ftask\u002Finode storage, devmap\u002Fcpumap\u002Fxskmap |\n| **BPF helpers** | ~200 typed Go stubs auto-generated from libbpf v1.5.0 headers. The ones exercised by `example\u002Fhelloworld\u002F` and `example\u002Fsysmon\u002F` are tested in real-kernel CI; the rest are unverified. File an issue if a stub doesn't match the kernel signature |\n| **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 |\n| **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) |\n| **User-defined helpers** | ✅ top-level Go funcs without `\u002F\u002Fbpf:section` are emitted as `static __always_inline` C functions |\n| **Typed Go bindings** | ✅ `Load\u003CStem>`, `Close`, per-program `Attach\u003CName>`, `AttachAll`, plus your kernel-side struct types and constants re-published in Go |\n| **Kernel-version gate** | ✅ [bpfvet](https:\u002F\u002Fgithub.com\u002Fboratanrikulu\u002Fbpfvet) runs at load time. Fails fast with `bpf program needs kernel >= 5.8, host is 5.4` instead of opaque `EINVAL` |\n| **Verifier error → Go source** | ✅ auto-annotated inside `Load\u003CStem>`. No manual pipe to `gobee diagnose`; `*ebpf.VerifierError` comes back with `→ counter.go:18:5` markers |\n| **Sourcemap sidecar** | ✅ `\u003Cstem>.bpf.c.map` written next to every `.bpf.c` for offline `gobee diagnose` use too |\n| **Cross-arch** | ✅ Linux arm64 + amd64 |\n\n## What gobee does\n\n- Transpiles a Go subset to BPF C (and runs `go\u002Ftypes` over your input first, so misuses surface at `file:line:col`).\n- Generates a typed `\u003CStem>_bindings.go` next 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.\n- Auto-annotates `*ebpf.VerifierError` from `LoadAndAssign` with Go source positions, no manual `gobee diagnose` pipe needed.\n- Runs [bpfvet](https:\u002F\u002Fgithub.com\u002Fboratanrikulu\u002Fbpfvet) inside `Load\u003CStem>` so old kernels fail fast with `bpf program needs kernel >= 5.8, host is 5.4`.\n- Surfaces ~200 typed Go stubs for the libbpf v1.5.0 helper set, plus user-defined helper functions emitted as `static __always_inline`.\n\n## What gobee won't do\n\n- **Replace clang.** clang's BPF backend gives us CO-RE, BTF, and verifier-friendly codegen for free. Reimplementing that costs years and gains nothing.\n- **Replace `cilium\u002Febpf`.** The generated bindings sit on top of it.\n- **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.\n- **Run clang for you.** Compile, embed, and load remain user-owned. Same pattern as bpf2go.\n\n## Why transpile, not generate BPF directly\n\n`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.\n\n## Quickstart\n\n```bash\ngo install github.com\u002Fboratanrikulu\u002Fgobee\u002Fcmd\u002Fgobee@latest\n\ncd example\u002Fhelloworld\nmake build                     # gobee translate, clang, go build\nsudo .\u002Fhelloworld eth0\n```\n\nYou'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.\n\n## Project layout (typical)\n\n```\nyourproject\u002F\n├── bpf\u002F                      # Go package, importable from anywhere in your project\n│   ├── embed_amd64.go        # \u002F\u002Fgo:embed bin\u002Fx86\u002Fyour.bpf.o\n│   ├── embed_arm64.go\n│   ├── your_bindings.go      # generated by gobee\n│   ├── bin\u002F{x86,arm64}\u002Fyour.bpf.o\n│   └── src\u002F                  # not a Go package; clang lives here\n│       ├── your.go           # \u002F\u002Fgo:build ignore: BPF source\n│       ├── your.bpf.c        # generated\n│       ├── Makefile          # clang per arch\n│       └── vmlinux.h         # vendored BTF dump\n├── main.go                   # imports yourproject\u002Fbpf\n└── Makefile\n```\n\nThe split keeps `bpf\u002F` a clean importable Go package (Go rejects `.c` files in non-cgo packages). Kernel sources and clang artifacts live one level down in `bpf\u002Fsrc\u002F`.\n\n## Examples\n\n- `example\u002Fhelloworld\u002F`: the canonical XDP packet counter, ~40 lines BPF, ~80 lines userspace.\n- `example\u002Fsysmon\u002F`: XDP, two tracepoints, and a kprobe in one binary, sharing a ringbuf for events. Demonstrates per-syscall typed contexts, user-defined helper functions, and the `AttachAll` shortcut.\n\n## CI\n\nGitHub Actions runs four layers on every push:\n\n1. `go test`, `go vet`, transpiler golden tests\n2. Coverage matrix: every map type and `\u002F\u002Fbpf:section` kind has at least one example\n3. clang compile of every curated example, then `bpfvet` portability report\n4. Real-kernel verifier acceptance: `ebpf.NewCollectionWithOptions` on each `.bpf.o` (Ubuntu 24.04 runner, kernel 6.x)\n\n## Docs\n\n- [`docs\u002Fdesign.md`](docs\u002Fdesign.md): architecture and rationale\n- [`docs\u002Fgo-subset.md`](docs\u002Fgo-subset.md): accepted Go syntax in BPF source files\n- [`docs\u002Fdirectives.md`](docs\u002Fdirectives.md): `\u002F\u002Fbpf:*` reference\n- [`docs\u002Fstatus.md`](docs\u002Fstatus.md): support matrix (single source of truth)\n\n## Toolchain\n\n- The gobee binary builds anywhere (pure Go, no CGO).\n- Compiling `.bpf.o` needs clang with the BPF target. Apple's bundled clang doesn't ship with it; on macOS use `brew install llvm` or build inside a Linux VM.\n- Running the artifact needs Linux on arm64 or amd64.\n\n## Inspirations\n\n- [Solod](https:\u002F\u002Fgithub.com\u002Fsolod-dev\u002Fsolod): the Go-to-C transpiler that proved this pattern works.\n- [Aya](https:\u002F\u002Fgithub.com\u002Faya-rs\u002Faya): the Rust eBPF framework whose ergonomics gobee chases.\n\n## License\n\nMIT. See [LICENSE](LICENSE).\n\nCopyright (c) 2026 Bora Tanrikulu <me@bora.sh>\n","gobee 是一个允许开发者使用 Go 语言编写 BPF 程序的工具，而不是传统的 C 语言。它能够将 Go 的一个严格子集转译成 BPF C 代码，并生成类型化的 cilium\u002Febpf 绑定，从而简化了从用户空间到内核空间的交互过程。该项目利用了 clang 成熟的后端技术来处理转译后的 C 代码，确保了编译效率和代码质量。适用于需要在 Linux 内核中运行高效跟踪或监控程序但又希望避免直接使用 C 语言开发的场景，尤其适合熟悉 Go 语言的开发者。","2026-06-11 03:56:30","CREATED_QUERY"]