On Tue, Mar 24, 2026 at 05:34:06PM +0000, Alan Maguire wrote:
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!
So the biggest reason I'm aware of is that those systems do not want to enable
BPF, and BTF is hidden behind BPF.
Other than that:
1. Toolchain qualifications for safety uses (we'd need to get pahole safety
certified).
2. On the ecosystem side, from what I saw, BTF isn't part of most BSPs that
vendors produce.
3. I saw concerns in the past about interactions with PREEMPT_RT, but I'm not
sure if it's still a thing.
--
Thanks,
Sasha
