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 17:06, Quentin Monnet wrote:
> 2026-09-16 08:41 UTC+0100 ~ Alan Maguire <alan.maguire@oracle.com>
>> 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)'
>>
>> and LOCSEC shows function name associated with site:
>>
>>   [15] LOCSEC 'inline.text' vlen=1
>>   	name=foo func_type_id=5 loc_proto_type_id=14 offset=64
>>
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>> ---
>>  tools/bpf/bpftool/btf.c | 169 ++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 169 insertions(+)
>>
>> diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
>> index bbe8f9ea144f..5e0cb5862811 100644
>> --- a/tools/bpf/bpftool/btf.c
>> +++ b/tools/bpf/bpftool/btf.c
>> @@ -51,6 +51,9 @@ static const char * const btf_kind_str[NR_BTF_KINDS] = {
>>  	[BTF_KIND_DECL_TAG]	= "DECL_TAG",
>>  	[BTF_KIND_TYPE_TAG]	= "TYPE_TAG",
>>  	[BTF_KIND_ENUM64]	= "ENUM64",
>> +	[BTF_KIND_LOC_PARAM]	= "LOC_PARAM",
>> +	[BTF_KIND_LOC_PROTO]	= "LOC_PROTO",
>> +	[BTF_KIND_LOCSEC]	= "LOCSEC",
>>  };
>>  
>>  struct sort_datum {
>> @@ -117,6 +120,83 @@ static int btf_kind_safe(int kind)
>>  	return kind <= BTF_KIND_MAX ? kind : BTF_KIND_UNKN;
>>  }
>>  
>> +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]);
>> +			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)) {
>> +		switch (vlen - i) {
>> +		case 1:
>> +			value = p->values[i];
>> +			break;
>> +		case 2:
>> +			value = ((__u64)p->values[i + 1] << 32) | p->values[i];
>> +			break;
>> +		default:
>> +			snprintf(num, sizeof(num), "?");
>> +			goto done;
>> +		}
>> +		if ((p->flags & BTF_LOC_PARAM_SIGNED) && t->size &&
>> +		    t->size <= sizeof(value)) {
>> +			__u32 bits = t->size * 8;
> 
> 
> Hi Alan, thanks!
> 
> In the case of BTF_LOC_PARAM_OFFSET, what do we need "negative" for
> exactly, is this supposed to be the sign for the parameter or for the
> associated offset? My understanding is that "t->size" refers to the
> parameter itself, not the offset, so we would pick the wrong bit if
> trying to find the sign for the offset? But I'm not sure I read it
> correctly.

sorry, my previous reply had this wrong, I was mixing up an earlier
iteration. The idea here is we display the offset in hex but since we
can compute the sign it makes it clearer if we fix up the value for
display based on its signedness.

The code above has a bug tho; the size actually represents the size of
the final value rather than the size of the offset; the two can differ
for a case say where I have a REG|DEREF|OFFSET|SIGNED which has size 8 but
only has a 4-byte signed offset. We need to compute the signed value size
based on the type vlen, not the t->size since it is the overall size of
the result of dereferencing via the register value + offset. I'm fixing 
this and adding a test covering this in v4 and updating the UAPI to explain
it more clearly.

Again thanks for catching this!

> 
> 
>> +
>> +			if (t->size < sizeof(value))
>> +				value &= (1ULL << bits) - 1;
>> +			negative = value & (1ULL << (bits - 1));
>> +			if (negative)
>> +				value = t->size == sizeof(value) ? -value :
>> +					(1ULL << bits) - value;
>> +		}
>> +		snprintf(num, sizeof(num), "0x%llx", (unsigned long long)value);
> 
> 
> Looking at the different existing flags and their docs, I see:
> 
> "a BTF_LOC_PARAM_ADDR|BTF_LOC_PARAM_CONST is an address that should be
> normalized with respect to kernel/module base address."
> 
> But I don't see the output accounting for BTF_LOC_PARAM_ADDR, is this
> expected or is that an omission?
> 
> [...]
> 
> Please also look at Sashiko and bpf-ci's reviews for patch 7.
> 
> Thanks,
> Quentin