On 24/03/2026 16:00, Sasha Levin wrote: > On Tue, Mar 24, 2026 at 08:03:30AM -0700, Alexei Starovoitov wrote: >> On Mon, Mar 23, 2026 at 9:49 AM Sasha Levin <[email protected]> wrote: >>> >>> Embed DWARF-derived function parameter name and type information in the >>> kernel image so that oops and WARN dumps display the crashing function's >>> register-passed arguments with their names, types, and values. >>> >>> A new build-time tool (scripts/gen_paraminfo.c) parses DW_TAG_subprogram >>> and DW_TAG_formal_parameter entries from DWARF .debug_info, extracting >>> parameter names and human-readable type strings. The resulting tables are >>> stored in .rodata using the same two-phase link approach as lineinfo. >>> >>> At runtime, kallsyms_show_paraminfo() performs a binary search on the >>> paraminfo tables, maps parameters to x86-64 calling convention registers >>> (RDI, RSI, RDX, RCX, R8, R9), and prints each parameter's name, type, >>> and value from pt_regs. If a parameter value matches the page fault >>> address (CR2), it is highlighted with "<-- fault address". >>> >>> Integration at show_regs() means this works for both oops and WARN() >>> automatically, since both paths provide full pt_regs at the exception >>> point. >>> >>> Example output: >>> >>> Function parameters (ext4_readdir): >>> file (struct file *) = 0xffff888123456000 >>> ctx (struct dir_context *) = 0x0000000000001234 <-- fault address >>> >>> Gated behind CONFIG_KALLSYMS_PARAMINFO (depends on >>> CONFIG_KALLSYMS_LINEINFO). >>> Adds approximately 1-2 MB to the kernel image for ~58K functions. >>> >>> Assisted-by: Claude:claude-opus-4-6 >>> Signed-off-by: Sasha Levin <[email protected]> >> >> Nack. >> >> You asked claude to reinvent pahole and BTF and it did it >> completely missing years of fine tuning that pahole does. > > Let's keep this on the technical side please. > >> dwarf cannot be trusted as-is. pahole converts it carefully >> by analyzing optimized out arguments and dropping signatures > > Fair point about pahole and optimized-out args. The problem is that BTF > depends > on BPF_SYSCALL, and the environments I care about can't enable either. > Automotive, robotics, and safety configs all have DWARF and KALLSYMS but no > path to BTF. >
Curious what the blockers are to BTF adoption? Hopefully we can tackle some of these or get them on a roadmap at least. I know some embedded folks want vmlinux BTF as a module instead of directly contained in the vmlinux binary to minimize vmlinux size; is this the problem you run into? Are there other issues? Any info you could provide would be great as the aim is to make BTF feasible in as many environments as possible. Thanks! Alan
