Re: [PATCH 1/2] kallsyms: show function parameter info in oops/WARN dumps

[Sasha Levin <sashal@kernel.org>]

On Tue, Mar 24, 2026 at 09:04:03AM -0700, Alexei Starovoitov wrote:
>On Tue, Mar 24, 2026 at 9:00 AM Sasha Levin <sashal@kernel.org> 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 <sashal@kernel.org> 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 <sashal@kernel.org>
>> >
>> >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.
>
>This is trivially fixable without reinventing pahole.

Hmm...

Looking at the code, I'd need to:

- Split BTF parsing from kernel/bpf/btf.c to somewhere outside of kernel/bpf/.
- New init path for btf_vmlinux outside BPF verifier.
- Refactor btf_parse_vmlinux() BPF-specific bits.
- Remove BPF_SYSCALL dependency from DEBUG_INFO_BTF.
- Somehow make BTF work with DEBUG_INFO_REDUCED.

I suppose that the first 4 are straightforward, but I don't have an idea about
DEBUG_INFO_REDUCED. Though we can probably tackle it later.

Does that make sense? Did I miss anything?

-- 
Thanks,
Sasha