Debugging information for inlined functions [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Debugging information for inlined functions
Please consider subscribing to LWN
Subscriptions are the lifeblood of LWN.net. If you appreciate this<br>content and would like to see more of it, your subscription will<br>help to ensure that LWN continues to thrive. Please visit<br>this page to join up and keep LWN on<br>the net.
By Daroc Alden<br>July 29, 2026
LSFMM+BPF
BPF programs use
BPF type format (BTF) debugging information in order to<br>determine how to interact with functions in the kernel. Specifically, tracing a<br>kernel function involves finding its address in the kernel's BTF section — but<br>that doesn't work for functions that have been inlined, and therefore don't have<br>a single, specific address. Alan Maguire wants to add information about inlined<br>functions to BTF in order to allow them to be traced, and led a session on that<br>topic at the 2026
Linux Storage, Filesystem, Memory-Management, and BPF Summit.
There are more than 100,000 inlined functions in the kernel, Maguire said,<br>spread across five times as many locations. Worse, some of them are partially<br>inlined: called normally in some places and inlined in others. That can lead to<br>cases today where it appears that a function was traced successfully, but some<br>invocations were not seen.
The good news is that the rest of the infrastructure for tracing inlined<br>functions is already in place to enable
kprobes, which can be attached to arbitrary<br>locations. It is just a matter of getting the data about where functions have<br>been inlined into a usable format, Maguire stated. "The story is actually<br>pretty complete."
So, what is needed to store this information in BTF? The
DWARF<br>debugging format already has a way to indicate inlining information, but DWARF<br>is also difficult to work with, and doesn't have a simple way to represent the<br>common cases. A solution for BTF should be compact, and permit<br>deduplication, to keep the memory overhead low, Maguire said. Ideally, inlining<br>information could be stored in a separate section of the kernel binary, or even<br>be distributed as a separate kernel module, so that it is not loaded until it is<br>needed.
Concretely, Maguire proposed three new pieces of information be added to BTF.<br>The first was inline-site-specific information about which function was inlined at<br>each call site<br>and how it would have been called if it had not been inlined, called the<br>"location section". That data can't be<br>easily deduplicated because it's specific to a given call site, so as much as<br>possible the information should consist of pointers to data that can be<br>deduplicated.
The second and third pieces of information he wants to add would be the<br>pointed-to data: a "location prototype" and "location parameter".<br>The location prototype specifies how the inlined function's arguments are<br>represented at the call site, as a list of pointers to location parameters,<br>which each store how to access a single function argument.<br>In theory, the compiler could store a given function parameter at a different<br>location for every inlined call site (of which there are 538,090);<br>in practice, there are a limited number of<br>ways that the compiler will transform parameters, and many functions<br>have compatible signatures that result in the compiler making the same choices.<br>In the current kernel, deduplicating location prototypes results in just 57,141<br>distinct entries referencing only 17,535 location parameter entries in total.
This means that the location sections take up most<br>of the added data. Overall, the additions to BTF that Maguire proposes would come to<br>approximately 11MB of additional data, or about 21 bytes per inlined call<br>site. When pulled out into a separate kernel module and compressed, the total<br>amount of data goes down to 3.5MB.
Maguire then went through an example of how information about a specific<br>function would be stored. Consider this function:
int foo(int a, void *b, bool c);
If the compiler chose to inline foo() in a way that eliminates<br>a as unused, promotes b to be passed in a<br>register, and determines that c is a constant, the BTF representation<br>would be a single location section entry storing the BTF type ID of<br>foo(), the offset of the call site from the kernel's base address in memory, and a pointer to the<br>location-prototype entry. That entry becomes a length-tagged<br>array of references to location-parameter entries. The first entry is null,<br>indicating that a cannot be recovered. The second points to a location<br>parameter entry with a flag that indicates the value is contained in a register,<br>and then the specific register number of b. The last location-parameter<br>entry has a different flag specifying that it is a constant, and then the value<br>of the constant.
Alexei Starovoitov...