| It sounds like you're mostly trying to use higher level toolkits like BCC and clang for eBPF, which I agree isn't a great experience, if you don't know what's going on underneath. I used to hand-code BPF before LLVM had a backend for it, and I can tell you that each enhancement added to the userland tooling made sense in isolation to help you if you already knew what you were doing. But the overall picture isn't really an SDK - it's more like a collection of someone's bash scripts used to automate repetitive parts of writing the bytecode. For one thing, 80% of the contents of the popular toolkits is just there to accomplish two goals: 1) Let you pretend to write C / some other higher level language
2) Cut down on manual set up of the maps, checking if BPF is enabled, etc. Arguably the only really complicated thing the tooling does is CO-RE, which is largely done in the loader, with some C macros to support it. What you pay for this "convenience" is that the kernel has no idea what the hell you're trying to do. All it sees is the generated, rewritten and relocated BPF bytecode which it has no way of tying back to the C code you made it from. To arrive at a point - I would honestly recommend trying to write BPF by hand. The bytecode is pretty friendly, the BPF helpers are numbered and you'll see what the verifier is talking about. After you've got that down, you'll see the two annoying parts: doing BTF-based relocations and doing the setup with BPF maps, etc, and you'll get a feeling for how the clang-based tooling does those things, and what cost it extracts: IMO it's not worth it. |