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

[Sasha Levin <sashal@kernel.org>]

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 <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.
>> 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