Re: FAILED unresolved symbol vfs_truncate on arm64 with LLVM

From: Sedat Dilek <sedat.dilek@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Veronika Kabatova <vkabatov@redhat.com>,
	Jiri Olsa <jolsa@kernel.org>
Subject: Re: FAILED unresolved symbol vfs_truncate on arm64 with LLVM
Date: Thu, 11 Feb 2021 17:36:16 +0100	[thread overview]
Message-ID: <CA+icZUU5rQ2da_MpKBCngZZR5mHTj5r6Pn_WovMu_C1PXd=1BQ@mail.gmail.com> (raw)
In-Reply-To: <YCVWONQEBLfO/i2z@krava>

On Thu, Feb 11, 2021 at 5:07 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Thu, Feb 11, 2021 at 04:43:48PM +0100, Sedat Dilek wrote:
>
> SNIP
>
> > > > filled with elf functions start/end values, right?
> > > >
> > > > >                         /*
> > > > >                          * We iterate over sorted array, so we can easily skip
> > > > >                          * not valid item and move following valid field into
> > > > >
> > > > >
> > > > > So the idea is to use address segments and check whether there is a
> > > > > segment that overlaps with a given address by first binary searching
> > > > > for a segment with the largest starting address that is <= addr. And
> > > > > then just confirming that segment does overlap with the requested
> > > > > address.
> > > > >
> > > > > WDYT?
> > >
> > > heya,
> > > with your approach I ended up with change below, it gives me same
> > > results as with the previous change
> > >
> > > I think I'll separate the kmod bool address computation later on,
> > > but I did not want to confuse this change for now
> > >
> >
> > I have applied your diff on top of pahole-v1.20 with Yonghong Son's
> > "btf_encoder: sanitize non-regular int base type" applied.
> > This is on x86-64 with LLVM-12, so I am not directly affected.
> > If it is out of interest I can offer vmlinux (or .*btf* files) w/ and
> > w/o your diff.
>
> if you could run your tests/workloads and check the new change does not
> break your stuff, that'd be great
>
> we need soem testsuite ;-) I have some stupid test script which runs over
> few vmlinux binaries and check the diff in BTF data.. problem is that these
> vmlinux binaries are ~300M each, so it's not great for sharing
>
> also I was checking if we could use BPF_BTF_LOAD syscall and load BTF in
> kernel and back at the end of pahole processing to check it's valid ;-)
>

Just finished a new build.

What I did:

cd /path/to/linux/git
rm -v .*btf* vmlinux*
<re-run my build-script with modified pahole>

I collected some commands in CBL issue #1297.

$ /usr/sbin/bpftool btf dump file vmlinux | rg 'vfs_truncate|bpf_d_path'
[22259] TYPEDEF 'btf_bpf_d_path' type_id=22260
[29970] FUNC 'vfs_truncate' type_id=29969 linkage=static

Tests?

$MAKE $MAKE_OPTS -C tools/testing/selftests/bpf/

^^^ ???

- Sedat -

[1] https://github.com/ClangBuiltLinux/linux/issues/1297

> thanks,
> jirka
>