From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Veronika Kabatova <vkabatov@redhat.com>,
Andrii Nakryiko <andriin@fb.com>,
Alexei Starovoitov <ast@kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
bpf <bpf@vger.kernel.org>, "Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: Build failures: unresolved symbol vfs_getattr
Date: Tue, 15 Sep 2020 14:17:43 +0200 [thread overview]
Message-ID: <20200915121743.GA2199675@krava> (raw)
In-Reply-To: <20200915073030.GE1714160@krava>
On Tue, Sep 15, 2020 at 09:30:33AM +0200, Jiri Olsa wrote:
> On Mon, Sep 14, 2020 at 03:26:33PM -0700, Andrii Nakryiko wrote:
> > On Mon, Sep 14, 2020 at 11:25 AM Jiri Olsa <jolsa@redhat.com> 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?
>
> sorry I cut the original message, there's following container that
> reproduces the issue:
>
> The failure is easily reproduced with our container image that already
> has all the needed dependencies installed:
> registry.gitlab.com/cki-project/containers/builder-rawhide:latest
>
> Steps to reproduce after starting the image:
>
> git clone https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git --depth 1
> curl https://gitlab.com/-/snippets/2014934/raw -o bpf-next/.config
> cd bpf-next/
> make -j 10 INSTALL_MOD_STRIP=1 targz-pkg
>
>
> [root@30a9be783e4e /]# gcc --version
> gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)
>
> I built the latest pahole in that container and still see the issue,
> I also tried with v1.16 version and it's still there
>
> I don't see the issue when I build kernel with another .config
> so I'll try to check on that now
readelf --debug has 2 records for vfs_getattr
fs/stat.c and include/linux/fs.h
fs/stat.c:
<1><11f9847>: Abbrev Number: 119 (DW_TAG_subprogram)
<11f9848> DW_AT_external : 1
<11f9848> DW_AT_name : (indirect string, offset: 0x9eaeb): vfs_getattr
<11f984c> DW_AT_decl_file : 1
<11f984d> DW_AT_decl_line : 116
<11f984e> DW_AT_decl_column : 5
<11f984f> DW_AT_prototyped : 1
<11f984f> DW_AT_type : <0x11ebe32>
<11f9853> DW_AT_inline : 1 (inlined)
<11f9854> DW_AT_sibling : <0x11f9895>
<2><11f9858>: Abbrev Number: 35 (DW_TAG_formal_parameter)
<11f9859> DW_AT_name : (indirect string, offset: 0x70041): path
<11f985d> DW_AT_decl_file : 1
<11f985e> DW_AT_decl_line : 116
<11f985f> DW_AT_decl_column : 36
<11f9860> DW_AT_type : <0x11f17ed>
<2><11f9864>: Abbrev Number: 35 (DW_TAG_formal_parameter)
<11f9865> DW_AT_name : (indirect string, offset: 0x5fa1): stat
<11f9869> DW_AT_decl_file : 1
<11f986a> DW_AT_decl_line : 116
<11f986b> DW_AT_decl_column : 56
<11f986c> DW_AT_type : <0x11f41e0>
<2><11f9870>: Abbrev Number: 35 (DW_TAG_formal_parameter)
<11f9871> DW_AT_name : (indirect string, offset: 0x8e714): request_mask
<11f9875> DW_AT_decl_file : 1
<11f9876> DW_AT_decl_line : 117
<11f9877> DW_AT_decl_column : 7
<11f9878> DW_AT_type : <0x11ebe93>
<2><11f987c>: Abbrev Number: 35 (DW_TAG_formal_parameter)
<11f987d> DW_AT_name : (indirect string, offset: 0xd789): query_flags
<11f9881> DW_AT_decl_file : 1
<11f9882> DW_AT_decl_line : 117
<11f9883> DW_AT_decl_column : 34
<11f9884> DW_AT_type : <0x11ebde1>
include/linux/fs.h:
<1><140d794>: Abbrev Number: 43 (DW_TAG_subprogram)
<140d795> DW_AT_external : 1
<140d795> DW_AT_name : (indirect string, offset: 0x9eaeb): vfs_getattr
<140d799> DW_AT_decl_file : 7
<140d79a> DW_AT_decl_line : 3148
<140d79c> DW_AT_decl_column : 12
<140d79d> DW_AT_prototyped : 1
<140d79d> DW_AT_type : <0x140611a>
<140d7a1> DW_AT_sibling : <0x140d7ba>
<2><140d7a5>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<140d7a6> DW_AT_type : <0x14087aa>
<2><140d7aa>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<140d7ab> DW_AT_type : <0x140cfb6>
<2><140d7af>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<140d7b0> DW_AT_type : <0x1406176>
<2><140d7b4>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<140d7b5> DW_AT_type : <0x14060c9>
<2><140d7b9>: Abbrev Number: 0
the latter is just declaration.. but it's missing the
<365d69d> DW_AT_declaration : 1
so it goes through pahole's function processing:
cu__encode_btf:
...
cu__for_each_function(cu, core_id, fn) {
int btf_fnproto_id, btf_fn_id;
if (fn->declaration || !fn->external)
continue;
...
CC-ing Frank.. any idea why is the DW_AT_declaration : 1 missing?
thanks,
jirka
next prev parent reply other threads:[~2020-09-15 12:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1723352278.11013122.1600093319730.JavaMail.zimbra@redhat.com>
2020-09-14 14:48 ` Build failures: unresolved symbol vfs_getattr Veronika Kabatova
2020-09-14 18:25 ` Jiri Olsa
2020-09-14 22:26 ` Andrii Nakryiko
2020-09-15 7:30 ` Jiri Olsa
2020-09-15 12:17 ` Jiri Olsa [this message]
2020-09-16 9:06 ` Jiri Olsa
2020-10-16 21:38 ` Jiri Olsa
2020-10-21 19:42 ` Jiri Olsa
2020-10-22 20:00 ` Andrii Nakryiko
2020-10-23 5:36 ` Jiri Olsa
2020-10-23 6:58 ` Jiri Olsa
2020-10-23 18:22 ` Andrii Nakryiko
2020-10-23 20:17 ` Jiri Olsa
2020-10-23 20:32 ` Andrii Nakryiko
2020-10-23 20:45 ` Jiri Olsa
2020-10-23 22:02 ` Andrii Nakryiko
2020-10-26 10:14 ` Jiri Olsa
2020-10-26 22:06 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200915121743.GA2199675@krava \
--to=jolsa@redhat.com \
--cc=acme@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=fche@redhat.com \
--cc=vkabatov@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.