linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Rogers <irogers@google.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Michael Petlan <mpetlan@redhat.com>,
	linux-perf-users@vger.kernel.org,
	Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH 1/2] perf tools: Add more weak libbpf functions
Date: Tue, 9 Nov 2021 10:49:53 -0800	[thread overview]
Message-ID: <CAP-5=fVS2AwZ9bP4BjF9GDcZqmw5fwUZ6OGXdgMnFj3w_2OTaw@mail.gmail.com> (raw)
In-Reply-To: <20211109140707.1689940-2-jolsa@kernel.org>

On Tue, Nov 9, 2021 at 6:07 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> We hit the window where perf uses libbpf functions, that did not
> make it to the official libbpf release yet and it's breaking perf
> build with dynamicly linked libbpf.
>
> Fixing this by providing the new interface as weak functions which
> calls the original libbpf functions. Fortunatelly the changes were
> just renames.

Could we just provide these functions behind a libbpf version #if ?
Weak symbols break things in subtle ways, under certain circumstances
the weak symbol is preferred over the strong due to lazy object file
resolution:
https://maskray.me/blog/2021-06-20-symbol-processing#archive-processing
This bit me last week, but in general you get away with it as the lazy
object file will get processed in an archive exposing the strong
symbol. With an #if you either get a linker error for 2 definitions or
0 definitions, and it's clear what is broken.

In the past we had problems due to constant propagation from weak
const variables, where #if was the solution:
https://lore.kernel.org/lkml/20191001003623.255186-1-irogers@google.com/

There was some recent conversation on libbpf version for pahole here:
https://lore.kernel.org/bpf/CAP-5=fUc3LtU0WYg-Py9Jf+9picaWHJdSw=sdOMA54uY3p1pdw@mail.gmail.com/T/
https://lore.kernel.org/bpf/20211021183330.460681-1-irogers@google.com/

Thanks,
Ian

> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  tools/perf/util/bpf-event.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
> index 4d3b4cdce176..ceb96360fd12 100644
> --- a/tools/perf/util/bpf-event.c
> +++ b/tools/perf/util/bpf-event.c
> @@ -33,6 +33,33 @@ struct btf * __weak btf__load_from_kernel_by_id(__u32 id)
>         return err ? ERR_PTR(err) : btf;
>  }
>
> +struct bpf_program * __weak
> +bpf_object__next_program(const struct bpf_object *obj, struct bpf_program *prev)
> +{
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +       return bpf_program__next(prev, obj);
> +#pragma GCC diagnostic pop
> +}
> +
> +struct bpf_map * __weak
> +bpf_object__next_map(const struct bpf_object *obj, const struct bpf_map *prev)
> +{
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +       return bpf_map__next(prev, obj);
> +#pragma GCC diagnostic pop
> +}
> +
> +const void * __weak
> +btf__raw_data(const struct btf *btf_ro, __u32 *size)
> +{
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +       return btf__get_raw_data(btf_ro, size);
> +#pragma GCC diagnostic pop
> +}
> +
>  static int snprintf_hex(char *buf, size_t size, unsigned char *data, size_t len)
>  {
>         int ret = 0;
> --
> 2.31.1
>

  reply	other threads:[~2021-11-09 18:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 14:07 [PATCH 0/2] perf tools: Fix perf build with dynamic libbpf Jiri Olsa
2021-11-09 14:07 ` [PATCH 1/2] perf tools: Add more weak libbpf functions Jiri Olsa
2021-11-09 18:49   ` Ian Rogers [this message]
2021-11-09 23:33     ` Andrii Nakryiko
2021-11-10  8:45       ` Jiri Olsa
2021-11-10 22:37         ` Andrii Nakryiko
2021-11-11  7:14           ` Jiri Olsa
2021-11-10  8:39     ` Jiri Olsa
2021-11-13 13:40     ` Arnaldo Carvalho de Melo
2021-11-09 14:07 ` [PATCH 2/2] perf tools: Add weak variants for the deprecated " Jiri Olsa

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='CAP-5=fVS2AwZ9bP4BjF9GDcZqmw5fwUZ6OGXdgMnFj3w_2OTaw@mail.gmail.com' \
    --to=irogers@google.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrii@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@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;
as well as URLs for NNTP newsgroup(s).