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


 
> Also, it appears that simply enumerating all possible flag
> combinations in a switch would make this function easier to audit for
> not-handled expressions (like ADDR), or plainly reporting that the
> flags are unknown for this version of the tool.
> 
> [1] https://github.com/eddyz87/inline-address-printer/blob/master/main.c#L107
> 
>> +			break;
>> +		case 1:
>> +			snprintf(regs, sizeof(regs), "r%u", p->values[0]);
>> +			break;
>> +		default:
>> +			snprintf(regs, sizeof(regs), "?");
>> +			break;
>> +		}
>> +		i += nregs;
>> +	}
>> +	if (p->flags & (BTF_LOC_PARAM_CONST|BTF_LOC_PARAM_OFFSET)) {
> 
> ...
>