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

[Alan Maguire <alan.maguire@oracle.com>]

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.

> jirka
> 
>> we augment pfunct [1] to support this; it already has an option to display inline expansions
>> from DWARF, so having a BTF-based expansion of inline sites there seems like it would
>> be a more natural fit, what do you think? Thanks!
>> 
>> Alan
>> 
>> [1] https://github.com/acmel/dwarves/blob/master/man-pages/pfunct.1
>> 
>>  
>> > jirka
>> > 
>> 
>