Re: [PATCH v3 bpf-next 2/3] bpftool: Update func representation to include function signature

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

On 28/09/2026 10:39, Jiri Olsa wrote:
> 
> On Sat, Sep 26, 2026 at 06:51:12PM +0100, Alan Maguire wrote:
> 
> SNIP
> 
>> +static void btf_locsec_func_str(const struct btf *btf,
>> +				const struct btf_loc *loc, char *str, size_t sz)
>> +{
>> +	const struct btf_type *func, *func_proto, *loc_proto;
>> +	const struct btf_param *params;
>> +	const __u32 *loc_params;
>> +	const char *name;
>> +	__u32 i, vlen;
>> +	size_t off = 0;
>> +
>> +	if (!sz)
>> +		return;
>> +
>> +	str[0] = '\0';
>> +	func = btf__type_by_id(btf, loc->func);
>> +	if (!func || !btf_is_func(func))
>> +		goto invalid;
>> +
>> +	name = btf_str(btf, func->name_off);
>> +	func_proto = btf__type_by_id(btf, func->type);
>> +	loc_proto = btf__type_by_id(btf, loc->loc_proto);
>> +	if (!func_proto || !btf_is_func_proto(func_proto) ||
>> +	    !loc_proto || !btf_is_loc_proto(loc_proto) ||
>> +	    btf_vlen(func_proto) != btf_vlen(loc_proto))
>> +		goto invalid;
>> +
>> +	params = (const void *)(func_proto + 1);
>> +	loc_params = btf_loc_proto_params(loc_proto);
>> +	vlen = btf_vlen(func_proto);
>> +	if (!btf_locsec_append(str, sz, &off, name) ||
>> +	    !btf_locsec_append(str, sz, &off, "("))
>> +		return;
>> +	for (i = 0; i < vlen; i++) {
>> +		const struct btf_type *param_loc;
>> +		char param_str[256] = {};
>> +
>> +		if (!params[i].type) {
>> +			/* Handle varargs func proto, must be last parameter */
>> +			if (i != vlen - 1)
>> +				goto invalid;
>> +			if (!btf_locsec_append(str, sz, &off, i ? ", " : "") ||
>> +			    !btf_locsec_append(str, sz, &off, "..."))
>> +				return;
>> +			break;
>> +		} else if (loc_params[i]) {
>> +			param_loc = btf__type_by_id(btf, loc_params[i]);
>> +			btf_loc_param_str(param_loc, param_str, sizeof(param_str));
>> +		} else {
>> +			snprintf(param_str, sizeof(param_str), "<unavailable>");
> 
> hi,
> I'm getting many unavailable arguments, like:
> 
> jolsa@krava4:~/kernel/linux-qemu-1$ ./tools/bpf/bpftool/bpftool btf dump file /tmp/vmlinux+inline | grep func | grep '<unavailable>' | head -10
> 	func='cpumask_test_cpu(cpu [reg0], cpumask [<unavailable>])' func_type_id=171851 loc_proto_type_id=171852 offset=7674
> 	func='instrument_atomic_check_alignment(v [<unavailable>], size [const 0x8])' func_type_id=171855 loc_proto_type_id=171857 offset=7681
> 	func='instrument_atomic_read(v [<unavailable>], size [const 0x8])' func_type_id=171858 loc_proto_type_id=171857 offset=7681
> 	func='variable_test_bit(nr [*(reg0)], addr [<unavailable>])' func_type_id=171860 loc_proto_type_id=171862 offset=7681
> 	func='arch_test_bit(nr [*(reg0)], addr [<unavailable>])' func_type_id=171864 loc_proto_type_id=171862 offset=7681
> 	func='_test_bit(nr [*(reg0)], addr [<unavailable>])' func_type_id=171865 loc_proto_type_id=171862 offset=7681
> 	func='__srcu_read_lock_fast(ssp [<unavailable>])' func_type_id=171867 loc_proto_type_id=171868 offset=7691
> 	func='srcu_read_lock_fast_notrace(ssp [<unavailable>])' func_type_id=171869 loc_proto_type_id=171868 offset=7691
> 	func='class_srcu_fast_notrace_constructor(l [<unavailable>])' func_type_id=171871 loc_proto_type_id=171868 offset=7691
> 	func='__srcu_read_unlock_fast(ssp [<unavailable>], scp [reg3])' func_type_id=171873 loc_proto_type_id=171875 offset=7727
> jolsa@krava4:~/kernel/linux-qemu-1$ ./tools/bpf/bpftool/bpftool btf dump file /tmp/vmlinux+inline | grep func | grep '<unavailable>' | wc -l
> 157950
> 
> I found on the pahole site 
> 
>   /* A zero id in LOC_PROTO represents unavailable location data. */
> 
> so I guess it's just not present in dwarf for some reason
>

yep; this matches my observation; of about 600,000 function I see around 80%
have all parameters available, so ~120,000 functions have one or more unavailable,
either due to missing location info or overly-complex location expressions.

IIRC this fits with Eduard's observations earlier on. I tried exploring adding
more location expression supports (logical operators etc) but none appeared to
add enough additional sites to be worth the added complexity. 

Thanks for testing!

Alan