BPF proposes r3-based unwinding for Rust and C++ cleanup

Alexei Starovoitov has posted a five-part series that teaches the BPF verifier and JITs to unwind through subprograms using register r3, so Rust panics and C++ exceptions can run Drop implementations and destructors instead of discarding the stack.

Today bpf_throw() abandons frames. The verifier therefore refuses to load a program that might throw while holding a lock or a reference. In Rust, index checks and unwrap can panic, so rust-bpf has been forced to strip landing pads and treat every panic as a throw. Programs that panic under a guard simply do not load.

An earlier approach kept the fast path clean with LLVM unwind tables, a kernel walker, new uapi, two kfuncs, and substantial libbpf work. Starovoitov’s alternative has LLVM emit ordinary instructions: a call, then a test of r3 that branches to a landing pad on unwind, with resume and raise paths setting r3 and exiting. Pads are normal code the verifier already understands, so the verifier delta stays small. Subprograms that participate are marked with a BTF decl_tag "unwind". There is no new uapi, no kfuncs, and nothing for libbpf or other loaders to do. The source-level entry point is the Itanium ABI’s _Unwind_RaiseException, which Rust and C++ runtimes already call elsewhere.

x86-64 and arm64 JITs opt in and move the post-call branch off the common path by rewriting the callee’s return address through the existing exception-table machinery when r3 signals unwind. A JIT that cannot preserve r3 simply does not advertise support. Untagged C programs are unaffected. Tail calls and ld_abs are rejected on unwindable subprogs, and only fentry may attach to them.

Selftests cover verifier rules, attachment limits, and a C++ program with try/catch and scoped guards whose destructors must run in order. rust-bpf is already switching to panic=unwind under this convention. The series is aimed at bpf-next.