BTF patches aim to let BPF tracers reach inlined functions

Alan Maguire has posted a second-round patch series for bpf-next that extends the BPF Type Format (BTF) so tracers can instrument functions that the compiler inlined away.

Inline expansion is common in the kernel, but it leaves kprobe-style tools without a reliable map from call site back to the original function and its parameters. Maguire's approach adds location-oriented BTF kinds that record, for each inline site, which function was folded in, how each argument is represented at that point (register, constant, dereference, or unavailable), and a base-relative offset that still works under kASLR and for loadable modules.

Scale is the hard part. Local bpf-next builds show nearly 600,000 inline sites across roughly 100,000 functions, so the design leans on heavy deduplication. On a vmlinux whose ordinary BTF is about 6 MB, the extra inline data runs to roughly 10.8 MB. Full recoverable parameter locations exist for about 78 percent of sites; the rest use more complex encodings or omit values.

To limit the hit on the main image, the series can ship the inline blob as a compressed loadable module (about 3.5 MB). Opening the corresponding sysfs node loads that module on demand, so the user-visible path stays the same whether the data is built in or modular. Supporting changes cover the kernel BTF verifier, libbpf construction and dump helpers, bpftool multi-split BTF handling, resolve_btfids extraction, and selftests that exercise kernel, in-tree module, and out-of-tree module cases.

If merged, the work would close a long-standing gap for BPF-based tracers and debuggers that today simply cannot see many hot inlined paths.