This blog post is the third installment in our eBPF blog post series, following our posts about eBPF selftests and eBPF trampolines.
In the previous blog post, we discussed how eBPF trampolines are dynamically generated to allow hooking tracing programs to functions’ entry and/or exit. Each trampoline is tailored specifically for the target function on which we want to hook programs: it is then able to read the function context (e.g. function arguments and return value) and to pass those to the hooked programs. However there is one detail that we did not address: how does the trampoline generator know exactly about the function layout? To be able to generate trampolines that can read and store the function arguments, the trampoline generator needs many details about each argument: the location (a register? If so, which one? Or maybe it is on the stack? And if so, at which offset?) and its size. Parsing the function machine code is not enough to learn about those, and even if it was, compiler optimizations would obfuscate this kind of info even more. What if besides the actual executable code, the kernel image could be bearing some data about its internal functions? In this post, we will dive into the DWARF debug information format, and the BPF Type Format (BTF) derived from it to support such a purpose.
Continue reading “The Dwarves Beneath the Kernel: Forging BTF for eBPF”

Linux 6.17
The
It’s been a few months already that Benoît Monin joined our team, as he started in May, just in time to participate to our yearly company-wide team week event in June. Benoît graduated from
More recently, in late August, Benjamin Robin also joined our team. This time, he joined just in time to participate to the recent Open Source Summit Europe in Amsterdam, a great opportunity to meet almost the entire Bootlin’s team, and also the embedded Linux community. Benjamin also graduated from
Bootlin had a very strong presence at the recent 


