From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A4076408258; Tue, 24 Mar 2026 18:51:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774378302; cv=none; b=Vu7puVQHQG0oNmSDwOkCwVQQEI/xjQ9NfDU2AO4f/5PxaIEB9kfk4HG0EaBSBihbBv+IFf0gCH363C8oGw1FN+zoe3P7VKj6F0GeezTTYVLvX1Kdn+tH/OuGvE3lXfWdcgPdrs6i9jYUKOPWEzJlr33Red+thbL1Nh2mobhkce8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774378302; c=relaxed/simple; bh=wtRzYnIH+bMH7Ye72CQ2Kv9676KwiVZQu06Yl7jdjr0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AVXakbsvbPkXjxdQK1EMRY6zQgsz8VMwzSM7ePp1eiZM48Un33UVoc4LUOBy53u8sbcLTkgFTfqx3kAFo+dSPFl+R5zVL54tE6MceXxwtqKJGdLa4+wq+yR5vPNH/2PKF2wL2e9ixdlXvsbioeygNip+zUcRnCQcnJgaCRN7yhQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nj5MLm82; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nj5MLm82" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E21EDC19424; Tue, 24 Mar 2026 18:51:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774378302; bh=wtRzYnIH+bMH7Ye72CQ2Kv9676KwiVZQu06Yl7jdjr0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nj5MLm820D8jXHlqIW13S77Dxa/WXF6aR4rqmdgRqf+Llxz2eXskd9y7mH/tR2sMQ LjOGcPEop83DcjXRCbya6BgyoBuSMzFDMwaqv3ImJnCkzMkRfzUf/VL247rGvzkHUk beQn6cXTn4t/aE7Z3iwSP38fq87xYhrRY0E3pELUwN8N1IxLGCMmK3s46xzFO8/4ZY rHVT1HUDflcJg4mX10tyHOL79mJmu1r6atkuGzBk9kEcXrQOxaWC+F/M9Hu4p/slIw C011knvbK4VIpiTEQHAFXsfGleDFA9iyqO1Xw8rL7mv4FNWC0adN9sz/NCl5sky3E5 B0Sg17maltdqg== Date: Tue, 24 Mar 2026 14:51:40 -0400 From: Sasha Levin To: Alan Maguire Cc: Alexei Starovoitov , Andrew Morton , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Josh Poimboeuf , Petr Mladek , Alexei Starovoitov , Jonathan Corbet , David Gow , Kees Cook , Greg KH , Luis Chamberlain , Steven Rostedt , Helge Deller , Randy Dunlap , Geert Uytterhoeven , Juergen Gross , James Bottomley , Alexey Dobriyan , Vlastimil Babka , Laurent Pinchart , Petr Pavlu , X86 ML , LKML , Linux Kbuild mailing list , "open list:DOCUMENTATION" , linux-modules@vger.kernel.org, bpf Subject: Re: [PATCH 1/2] kallsyms: show function parameter info in oops/WARN dumps Message-ID: References: <20260323164858.1939248-1-sashal@kernel.org> <20260323164858.1939248-2-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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 >>> >>> 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