Apologies. Indeed, not all generated clang eBPF is loadable eBPF. So we can sum up: - Clang can compile C - eBPF backend can generate the eBPF bytecode for su

Apologies. Indeed, not all generated clang eBPF is loadable eBPF. So we can sum up: - 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.