BTF gains compact encoding for inline function probe sites

BPF Type Format is gaining a compact way to describe where the compiler inlined functions, so tracers can place kprobe-style instrumentation at those sites instead of only at the original function entry.

Alan Maguire of Oracle posted a fourth revision of the work on the BPF list. Kernel builds can expose on the order of 600,000 inline sites across roughly 100,000 functions. Without careful encoding and deduplication, shipping that volume of debug detail in BTF would be prohibitive.

The design adds three related BTF kinds. Location parameters capture how an argument appears at a given site (register, constant, dereference, and similar forms). Location prototypes group those parameter descriptions for a site. Location sections, named after the code section they cover, list triples of inlined function type, location prototype, and offset from the section or module base so kASLR and loadable modules stay addressable.

Maguire reports full parameter recoverability for about 78 percent of inlined functions; the rest use more complex multi-expression forms or omit arguments. The series covers kernel verification, libbpf handling (including dedup and split/distilled BTF rules), bpftool dump and multi-base split BTF support for module .inline data, selftests, and the BTF specification. Generation of the inline data itself is left to pahole once the libbpf interfaces land, with resolve_btfids expected to separate inline and non-inline BTF.

Eduard Zingerman acked several of the supporting patches. The practical payoff is that BPF tracers can target inlined helpers and hot paths that previously disappeared into the caller's body, using the same BTF-driven tooling already used for ordinary functions.