Re: [PATCH v3 bpf-next 09/11] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, Sep 18, 2026 at 10:19:33AM +0100, Alan Maguire wrote:
> On 17/09/2026 23:00, Jiri Olsa wrote:
> > On Thu, Sep 17, 2026 at 09:27:42AM +0100, Alan Maguire wrote:
> >> 
> >> 
> >> On 16/09/2026 23:07, Jiri Olsa wrote:
> >> > 
> >> > On Wed, Sep 16, 2026 at 08:41:16AM +0100, Alan Maguire wrote:
> >> >> In raw mode ensure we can dump new BTF kinds in normal/json format.
> >> >> BTF_KIND_LOC_PARAMs are rendered as strings, for example a
> >> >> const value of 0x2a and a dereference of r10 + 0x20:
> >> >> 
> >> >>   [12] LOC_PARAM '(anon)' size=4 flags=0x2 vlen=1 values='0x2a'
> >> >>   [13] LOC_PARAM '(anon)' size=8 flags=0x38 vlen=2 values='*(r10 + 0x20)'
> >> >> 
> >> >> LOC_PROTOs render the associated values of each of their
> >> >> LOC_PARAMs for easier readability:
> >> >> 
> >> >>   [14] LOC_PROTO '(anon)' vlen=2
> >> >>   	type_id=12 value='r1'
> >> >>   	type_id=13 value='*(r2 + 0x10)'
> >> > 
> >> > nit, AFAICT these are dwarf's registers numbers? could we output arch's register names?
> >> >
> >> 
> >> thanks for taking a look Jiri! You're right they are DWARF register numbers alright;
> >> the problem is to render them as arch register names we'd need to maintain per-arch
> >> tables in bpftool, which seems like the wrong place to host those. I'd suggest instead
> > 
> > is it that bad? I guess it's just simple fixed table
> > 
> > not sure how useful that output is with dwarf registers, you'll need to convert
> > it to arch regs anyway to make some sense of it.. we could save some tokens ;-)
> >
> 
> Well it is a raw dump; to draw the analogy with functions, we don't we print a C
> function prototype for a BTF_KIND_FUNC_PROTO; instead we print a set of BTF ids
> that comprise the parameters. The problem with converting it is it then becomes
> hard to relate the raw dump output back to what the BTF actually was, which is 
> often what you want to know when you're doing a raw dump. Now that pfunct supports
> split BTF I can roll support for printing per-site info including registers etc into
> it as part of the pahole changes respin.

ok, sounds good, thanks

jirka