On Mon, 2024-06-17 at 12:29 +0100, Alan Maguire wrote:
[...]
> The only thing I could come up with is we were usually lucky; when we
> misinterpreted the func as a var and looked its type up, we got
>
> int var_linkage = btf_var(vt)->linkage;
>
> ...and were lucky it never equalled 1 (BTF_VAR_GLOBAL_ALLOCATED):
>
> /* no need to patch up static or extern vars */
> if (var_linkage != BTF_VAR_GLOBAL_ALLOCATED)
> continue;
>
> In the case of a function, the above btf_var(vt) would really be
> pointing at the struct btf_type immediately after the relevant
> function's struct btf_type (since unlike variables, functions don't have
> metadata following them). So the only way we'd trip this bug would be if
> the struct btf_type following the func was had a name_off value that
> happened to equal 1 (BTF_VAR_GLOBAL_ALLOCATED).
>
> So maybe the sorting changes to BTF order resulted in us tripping on
> this bug, but regardless the fix seems right to me.
I've added the following debug logging:
sym = find_sym_by_name(obj, sec->sec_idx, STT_OBJECT, var_name);
if (!sym) {
+ const struct btf_type *nt;
pr_warn("failed to find symbol for variable '%s' in section '%s'\n", var_name, sec_name);
+ nt = btf__type_by_id(obj->btf, vi->type + 1);
+ pr_warn(" vi->type == %d\n", vi->type);
+ pr_warn(" next id %d kind '%s', name '%s' off %d\n",
+ vi->type + 1,
+ btf_kind_str(nt),
+ btf__str_by_offset(obj->btf, nt->name_off), nt->name_off);
return -ENOENT;
}
The output is as follows:
libbpf: failed to find symbol for variable 'bpf_dynptr_slice' in section '.ksyms'
libbpf: vi->type == 17
libbpf: next id 18 kind 'struct', name 'bpf_nf_ctx' off 1
This matches your analysis and hits the unlikely situation when
name_off of the next type is 1.
