13 ms·
There is a fair bit of co-evolution of the Linux BPF verifier and the BPF llvm backend. This means that the verifier is biased to do well on bytecode that is co
by lmb 5y ago
There is a fair bit of co-evolution of the Linux BPF verifier and the BPF llvm backend. This means that the verifier is biased to do well on bytecode that is commonly emitted by clang. I can imagine that other programming languages will run into the verifier rejecting their output if it differs to much from common clang output. (There is redbpf which compiles rust to BPF AFAIK, but it still uses llvm. There is also a gcc BPF backend, but I don't have experience with that.) The good news is that Linux upstream is receptive to bug reports!
- flakiness 5y agoSo it's more coupled than it appears. That makes sense. Thanks for the tip!
- Birch-san 5y agobpftrace is considering adding a new backend that wouldn't involve any LLVM[0]. Additionally, ply is another effort (which doesn't use LLVM) to build a DTrace-like frontend to BPF.[1] [0] https://github.com/iovisor/bpftrace/issues/1845 https://github.com/iovisor/bpftrace/issues/1845 [1] https://github.com/iovisor/ply https://github.com/iovisor/ply