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

[Quentin Monnet <qmo@kernel.org>]

2026-09-21 14:46 UTC-0700 ~ Eduard Zingerman <eddyz87@gmail.com>
> On Mon, 2026-09-21 at 19:47 +0100, Alan Maguire wrote:
>> On 18/09/2026 21:51, Eduard Zingerman wrote:
>>> On Wed, 2026-09-16 at 08:41 +0100, Alan Maguire wrote:
>>>
>>> ...
>>>
>>>> +static void btf_loc_param_str(const struct btf_type *t, char *str, size_t sz)
>>>> +{
>>>> +	const struct btf_loc_param *p;
>>>> +	__u32 i = 0, vlen;
>>>> +	__u64 value;
>>>> +	bool negative = false;
>>>> +	char regs[32] = {};
>>>> +	char num[32] = {};
>>>> +	const char *op = "";
>>>> +
>>>> +	if (!t || !btf_is_loc_param(t)) {
>>>> +		snprintf(str, sz, "<invalid>");
>>>> +		return;
>>>> +	}
>>>> +
>>>> +	p = btf_loc_param(t);
>>>> +	vlen = btf_vlen(t);
>>>> +
>>>> +	if (p->flags & BTF_LOC_PARAM_REG) {
>>>> +		__u32 nregs = (p->flags == BTF_LOC_PARAM_REG) ? vlen : 1;
>>>> +
>>>> +		if (nregs > vlen) {
>>>> +			snprintf(str, sz, "?");
>>>> +			return;
>>>> +		}
>>>> +
>>>> +		switch (nregs) {
>>>> +		case 2:
>>>> +			snprintf(regs, sizeof(regs), "r%u, r%u",
>>>> +				 p->values[0], p->values[1]);
>>>
>>> I agree with Jiri regarding the register names. It's not a huge table,
>>> e.g. [1], 20 lines for x86 ~> 100-200 lines that would not really
>>> change to handle all architectures that have BPF jits.
>>> And it would be very convenient for those using the tool.
>>>
>>
>> Yeah, it's doable, it's just that it is more portable when done in
>> pfunct; we can use dwfl interface to get register names [1]. With
>> pfunct changes in that tree we get output that is either arch-independent
>> (standalone BTF) or when combined with ELF info from vmlinux
>> gives us the arch-specific register names, containing function etc.
>> To see the inline site for ip_send_skb for example:
>>
>> $ pfunct --inline_sites -f ip_send_skb --elf vmlinux /sys/kernel/btf/vmlinux.inline
>> 0xffffffff8201f241 [ip_push_pending_frames+0x31, .text +0x101f241] ip_send_skb(struct net * net [%rbx], struct sk_buff * skb [%rax])
>>
>> (above does not need DWARF at all, just BTF + ELF info, so will work with a
>> debuginfo-stripped vmlinux)
>>
>> So for me the tool to reach for in understanding the raw BTF is
>> bpftool, whereas to apply the arch-specific transformations, locate the
>> absolute addresses etc I'd use pfunct. But that's just me; I'm happy to
>> go with the consensus here. Given the current library support, I think
>> maintaining per-arch tables in bpftool (rather than introducing a new
>> library dependency) would be the way to go if we do add it.
>>
>> Quentin, what do you think? Are per-arch tables for registers in bpftool
>> ok from your side? Thanks!
>>
>> Alan
>>
>> [1] https://github.com/alan-maguire/dwarves/blob/0da899665b04f16c3f68c0b736834a15e045c3c9/pfunct.c#L95
> 
> Adding dwfl as an (optional?) dependency for bpftool and reusing the
> same code as [1] might be an option as well.
> 
> ...


If we decide to go with arch-specific transformation, I think I'd rather
go with local tables rather than adding a dependency, unless it turns
out to be necessary. But Alan's argument makes sense to me, bpftool
prints the literal BTF encoding, and resolving to per-arch instructions
is probably best left to pfunct.

Quentin