August 12, 2026
Now you see it, now you trace it
Debugging Information for Inlined Functions
Linux devs cheer a fix for ‘invisible’ code while arguing over bloat and bragging rights
TLDR: Linux developers want to add extra debug data so tools can track code that gets hidden when the compiler folds it into other places. Commenters mostly love the fix, but the big fight is whether the added file size is a harmless rounding error or yet another case of developer convenience making everything fatter.
Kernel developers are trying to solve a very nerdy but very real headache: sometimes a bit of code gets folded into other code by the compiler, which makes it hard to track later. Alan Maguire’s pitch is to add extra map data so these previously “invisible” function calls can finally be traced properly. The practical upside is simple: people debugging the Linux kernel would stop missing some calls and getting a misleading picture of what the system is doing.
And yes, the community immediately turned that into a mini-drama festival. One camp was basically yelling, “Finally!” because today’s tools can claim a function was traced even when some calls quietly vanish. For people who live in performance and debugging land, that’s nightmare fuel. Another camp zoomed straight in on the extra size: roughly 11MB more data, or 3.5MB compressed if shipped separately. Cue the classic comments-section showdown between “that’s tiny in 2026” and “congrats, we’re adding megabytes so developers can chase edge cases at 3 a.m.”
The jokes practically wrote themselves. Commenters compared inlined functions to ghosts, stealth mode code, and the one friend who says they’re at the party but never appears in the group photo. Others loved the idea of keeping the extra info in a separate add-on so regular users don’t pay the cost, calling it the rare proposal that tries to keep both the debugging obsessives and the size hawks from starting a flame war. For kernel watchers, this was catnip: obscure plumbing issue, real-world impact, and just enough memory-bloat panic to keep the replies spicy.
Key Points
- •Alan Maguire proposed extending BTF so BPF tracing can handle kernel functions that have been inlined and therefore do not have a single address.
- •The article states that the kernel has more than 100,000 inlined functions across roughly five times as many locations, with some only partially inlined.
- •Existing tracing support is largely in place through kprobes; the missing piece is metadata describing where and how functions were inlined.
- •The proposal adds three BTF components: a location section, location prototypes, and location parameters, with deduplication used to reduce repeated metadata.
- •For the current kernel, the added metadata would total about 11MB, or roughly 21 bytes per inlined call site, falling to about 3.5MB when split into a compressed kernel module.