From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 088DEC433EF for ; Tue, 14 Sep 2021 19:02:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D80C861163 for ; Tue, 14 Sep 2021 19:02:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232400AbhINTDY (ORCPT ); Tue, 14 Sep 2021 15:03:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:37178 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230332AbhINTDY (ORCPT ); Tue, 14 Sep 2021 15:03:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 28F4660F6D; Tue, 14 Sep 2021 19:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631646126; bh=iWqBdQRcv7u4U3jnps38VmYB1/cJCZuG2xyCc90b5RY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IkP6N8TGLIoufvF5AX2GZRAGH3jjpkpY0FsoWP/r1Px4sD+Y2C2m+XXP2PWAYAh6L N8tPTrmf9jaPDutKyDNw6+bG7ECulcfeqsWgr2eCZil7JtiG7NbxnqfY41TyKlqq8+ xMAsB+DCxCQ5Dtv4WH5fPlR8PIt8IAWORdmBXz2cOG3tXota/KmSb+0QomnC5lzyIb 4l63adA0bJA9o9gnd3x1weIseTgtXX3XNI24qRMakJnx8UFKU989qfRtUZZ4rdgOI8 1dg3TrMhaBdvxd6HVJK6gqzjklErMoE3t17qnkAJGSWSN4NpMHAsQUkT/w7WSLouRd fZtE0KJ6dm9Yg== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id D66124038F; Tue, 14 Sep 2021 16:02:02 -0300 (-03) Date: Tue, 14 Sep 2021 16:02:02 -0300 From: Arnaldo Carvalho de Melo To: Andrii Nakryiko Cc: Jiri Olsa , Andrii Nakryiko , bpf , Alexei Starovoitov , Daniel Borkmann , "linux-perf-use." , Kernel Team Subject: Re: [PATCH perf] perf: ignore deprecation warning when using libbpf's btf__get_from_id() Message-ID: References: <20210914170004.4185659-1-andrii@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Em Tue, Sep 14, 2021 at 11:28:28AM -0700, Andrii Nakryiko escreveu: > On Tue, Sep 14, 2021 at 11:21 AM Jiri Olsa 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? > > 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(). It was made to build against the libbpf that comes with fedora 34, the distro I'm using, which is: ⬢[acme@toolbox perf]$ sudo dnf install libbpf-devel Package libbpf-devel-2:0.4.0-1.fc34.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! ⬢[acme@toolbox perf]$ cat /etc/redhat-release Fedora release 34 (Thirty Four) And we have 'make -C tools/perf build-test' that has one entry to build with LIBBPF_EXTERNAL=1, i.e. using whatever libbpf-devel package is installed in the distro, in addtion to statically linking with the libbpf in the kernel sources. That is done because several distros are linking perf with the libbpf they ship. When I merged the latest upstream this test failed, and I realized that some files in tools/perf/ had changed to make use of a new function and that was the reason for the build test failure. So I tried to provide a transition help for these cases, initially as a feature test that would look if that new function was available and if not, provide the fallback, but then ended up following Jiri's suggestion for a __weak function, as that involved less coding. - Arnaldo > > 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 > > > --- > > > 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 > > > > > -- - Arnaldo