Compiling to eBPF is hard! The compiler must:
- avoid loops (backwards jumps) - unroll everything
- inline everything - no function calls
Basically, it's impossible to use clang to generate eBPF without -O2. Sorry.
Basically, it's impossible to use clang to generate eBPF without -O2. Sorry.
That's a bit confusing, as the comment by praseodym shows the output from doing just that.
???
The idea is to compile to assembly which both fixes the bug, and is runnable by eBPF.
- Clang can compile C
- eBPF backend can generate the eBPF bytecode for subset of IR (AFAIU not all IR, not all "C" is okay for eBPF)
- verifier can accept or reject the generated eBPF.
The goal is to write C in such a way that will be generally sensible C but that will consistently yield loadable eBPF programs. This is not easy! Just recently I was debugging code where clang optmizer decided to merge two loads of 2 bytes into one load of 4 bytes. This made the verifier unhappy - the specific loads are rewritten to helper calls by verifier. The verifier knows what to do on 2-byte load at offset X, and 2-byte load at offset X+2. But it has no idea what to do with 4-byte load at offset X!
Writing C programs that will compile to valid, loadable eBPF requires a fair amount of voodoo.
Kind of sounds like having a specific eBPF transformation pass available in LLVM would be useful.
eg having it generate known-to-work-with-eBPF output