eBPF was crucial in debugging #11545 and #11556. It also has quite a bit of potential for future debugging, monitoring, performance analysis, and possibly even user facing features in terms of tracing (?)

Running it as a sidecar on my machine was very tedious, it's much nicer to have it in the engine itself and part of its logs. For the previous debugging I was shelling out to bpftrace, but getting that to build for wolfi was a nightmare and extremely slow, so trying out cilium/ebpf as a library directly.

• Downside is that rather than the higher-level bpftrace script, we gotta write some C code (that compiles to ebpf, no CGo or anything needed)
• Potential upsides in the long term are more flexibility and fine-grain control

LLMs (claude code + codex) seem to be consistently very good at converting "here's what I want to trace" into working ebpf programs. The two programs checked in here (ovl_inuse for debugging overlay in-use warnings + filetracer for tracing all file syscalls) were entirely written by them.

• Included a engine/ebpf/AGENTS.md to help out more here
• The idea generally speaking is that when debugging we can ask an LLM to update one of the existing progs or add a new one. On a case-by-case basis we can decide to check one in if it seems re-usable; but if the prog is one-off that's fine to just never merge.

We obviously don't want to always run these programs, currently they can be configured by:

1. explicitly setting an env var on the engine DAGGER_EBPF_PROG_<prog name>=y (e.g. DAGGER_EBPF_PROG_FILETRACER=y)
   • names are defined and mapped to impl at top of cmd/engine/main.go
2. If ExtraDebug is on, progs can be enabled by default by uncommenting entries in the defaultEbpfPrograms map at the top of cmd/engine/main.go
   • this is a little more convenient for local debugging since you're often changing code around anyways

Also added the ability to selectively enable progs per test workflow (add name of progs to new arg added in toolchains/test-split/engine-tests.gen.dang), which is useful when trying to debug CI-only flakes.

Overall the overhead of tracing seems to be extremely low. The filetracer prog that logs every file create/rename/delete/etc. doesn't seem to have much noticeable impact on test runtime (though the engine logs do have over 1 million lines)