On Mon, Sep 14, 2020 at 11:25 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
>
> On Mon, Sep 14, 2020 at 10:48:36AM -0400, Veronika Kabatova wrote:
> >
> > Hello,
> >
> > we tested the bpf-next tree with CKI and ran across build failures. The
> > important part of the build log is:
> >
> > 00:18:05 GEN .version
> > 00:18:05 CHK include/generated/compile.h
> > 00:18:05 LD vmlinux.o
> > 00:18:27 MODPOST vmlinux.symvers
> > 00:18:27 MODINFO modules.builtin.modinfo
> > 00:18:27 GEN modules.builtin
> > 00:18:27 LD .tmp_vmlinux.btf
> > 00:18:42 BTF .btf.vmlinux.bin.o
> > 00:19:13 LD .tmp_vmlinux.kallsyms1
> > 00:19:19 KSYM .tmp_vmlinux.kallsyms1.o
> > 00:19:22 LD .tmp_vmlinux.kallsyms2
> > 00:19:25 KSYM .tmp_vmlinux.kallsyms2.o
> > 00:19:28 LD vmlinux
> > 00:19:40 BTFIDS vmlinux
> > 00:19:40 FAILED unresolved symbol vfs_getattr
> > 00:19:40 make[2]: *** [Makefile:1167: vmlinux] Error 255
> > 00:19:40 make[1]: *** [scripts/Makefile.package:109: targz-pkg] Error 2
> > 00:19:40 make: *** [Makefile:1528: targz-pkg] Error 2
>
> hi,
> it looks like broken BTF data to me, I checked that build
> and found we have multiple records for functions, like
> for filp_close:
>
> [23381] FUNC_PROTO '(anon)' ret_type_id=19 vlen=2
> '(anon)' type_id=464
> 'id' type_id=960
> [23382] FUNC 'filp_close' type_id=23381 linkage=static
>
>
> [33073] FUNC_PROTO '(anon)' ret_type_id=19 vlen=2
> 'filp' type_id=464
> 'id' type_id=960
> [33074] FUNC 'filp_close' type_id=33073 linkage=static
>
>
> or vfs_getattr:
>
> [33513] FUNC_PROTO '(anon)' ret_type_id=19 vlen=4
> 'path' type_id=741
> 'stat' type_id=1095
> 'request_mask' type_id=29
> 'query_flags' type_id=8
>
> [33514] FUNC 'vfs_getattr' type_id=33513 linkage=static
>
> [1094] FUNC_PROTO '(anon)' ret_type_id=19 vlen=4
> '(anon)' type_id=741
> '(anon)' type_id=1095
> '(anon)' type_id=29
> '(anon)' type_id=8
>
> [35099] FUNC 'vfs_getattr' type_id=1094 linkage=static
>
>
> and because we go through all BTF data until we resolve all we have,
> the doubled funcs will screw our internal counter and we skip a function
>
> the change below will workaround that, but I think we should fail in
> this case.. if I'm not missing something 2 FUNC records for one function
> in BTF data
>
> $ pahole --version
> v1.17
>
> HEAD is 2bab48c5b Merge branch 'improve-bpf-tcp-cc-init'
>
> thoughts? thanks
Can't repro this locally. It must be some bad compiler + DWARF +
pahole interaction. Can you try building pahole from latest sources
and try again? Also, what compiler did you use? What Kconfig?
> jirka
>
>
> ---
> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
> index dfa540d8a02d..a33e56553e52 100644
> --- a/tools/bpf/resolve_btfids/main.c
> +++ b/tools/bpf/resolve_btfids/main.c
> @@ -525,7 +525,7 @@ static int symbols_resolve(struct object *obj)
> }
>
> id = btf_id__find(root, str);
> - if (id) {
> + if (id && !id->id) {
> id->id = type_id;
> (*nr)--;
> }
>
