From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH perf] perf: ignore deprecation warning when using libbpf's btf__get_from_id()
Date: Tue, 14 Sep 2021 20:55:50 +0200 [thread overview]
Message-ID: <YUDwNvoYJ/C+94gY@krava> (raw)
In-Reply-To: <CAEf4BzbU8Ok-7Fsp1uGZ4F6b5GPb58fk1YKgnGwx9+sUBq71tA@mail.gmail.com>
On Tue, Sep 14, 2021 at 11:28:28AM -0700, Andrii Nakryiko wrote:
> On Tue, Sep 14, 2021 at 11:21 AM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Tue, Sep 14, 2021 at 10:00:04AM -0700, Andrii Nakryiko wrote:
> > > Perf code re-implements libbpf's btf__load_from_kernel_by_id() API as
> > > a weak function, presumably to dynamically link against old version of
> > > libbpf shared library. Unfortunately this causes compilation warning
> > > when perf is compiled against libbpf v0.6+.
> > >
> > > For now, just ignore deprecation warning, but there might be a better
> > > solution, depending on perf's needs.
> >
> > HI,
> > the problem we tried to solve is when perf is using symbols
> > which are not yet available in released libbpf.. but it all
> > linkes in default perf build because it's linked statically
> > libbpf.a in the tree
> >
>
> If you are always statically linking libbpf into perf, there is no
> need to implement this __weak shim. Libbpf is never going to deprecate
> an API if a new/replacement API hasn't been at least in a previous
> released version. So in this case btf__load_from_kernel_by_id() was
> added in libbpf 0.5, and btf__get_from_id() was marked deprecated in
> libbpf 0.6 (not yet released, of course). So with that, do you still
> think we need this __weak re-implementation?
we package/build perf to dynamically link to libbpf, so there's
time window where perf already uses new libbpf function that has
not been released yet in libbpf and perf build fails
Arnaldo has another solution using feature detection and have ifdefs
to take care about that, but having the weak functions is less code
and seems more manageable
jirka
>
> I was wondering if this was done to make latest perf code compile
> against some old libbpf source code or dynamically linked against old
> libbpf. But if that's not the case, the fix should be a removal of
> __weak btf__load_from_kernel_by_id().
>
> > so now we have weak function with that warning disabled locally,
> > which I guess could work? also for future cases like that
> >
> > jirka
> >
> > >
> > > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> > > ---
> > > tools/perf/util/bpf-event.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
> > > index 683f6d63560e..1a7112a87736 100644
> > > --- a/tools/perf/util/bpf-event.c
> > > +++ b/tools/perf/util/bpf-event.c
> > > @@ -24,7 +24,10 @@
> > > struct btf * __weak btf__load_from_kernel_by_id(__u32 id)
> > > {
> > > struct btf *btf;
> > > +#pragma GCC diagnostic push
> > > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > > int err = btf__get_from_id(id, &btf);
> > > +#pragma GCC diagnostic pop
> > >
> > > return err ? ERR_PTR(err) : btf;
> > > }
> > > --
> > > 2.30.2
> > >
> >
>
next prev parent reply other threads:[~2021-09-14 18:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 17:00 [PATCH perf] perf: ignore deprecation warning when using libbpf's btf__get_from_id() Andrii Nakryiko
2021-09-14 18:21 ` Jiri Olsa
2021-09-14 18:28 ` Andrii Nakryiko
2021-09-14 18:55 ` Jiri Olsa [this message]
2021-09-14 19:02 ` Arnaldo Carvalho de Melo
2021-09-14 21:38 ` Andrii Nakryiko
2021-09-15 10:55 ` Toke Høiland-Jørgensen
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=YUDwNvoYJ/C+94gY@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=linux-perf-users@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox