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

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

...