Messages in this thread | | | Date | Wed, 10 Nov 2021 09:39:20 +0100 | From | Jiri Olsa <> | Subject | Re: [PATCH 1/2] perf tools: Add more weak libbpf functions |
| |
On Tue, Nov 09, 2021 at 10:49:53AM -0800, Ian Rogers wrote: > 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.
hum, I see 2 problems..
usinf #if works nicely for btf__raw_data because it's used directly, but bpf_object__next_program and bpf_object__next_map are used through macros:
#define bpf_object__for_each_map(pos, obj) \ for ((pos) = bpf_object__next_map((obj), NULL); \ (pos) != NULL; \ (pos) = bpf_object__next_map((obj), (pos)))
#define bpf_object__for_each_program(pos, obj) \ for ((pos) = bpf_object__next_program((obj), NULL); \ (pos) != NULL; \ (pos) = bpf_object__next_program((obj), (pos)))
we would need to provide 'old version' macro as well
another issue is more disturbing.. compiling with LIBBPF_DYNAMIC=1 still seems to take the in-kernel bpf headers, because we use
-I$(KTREE)/tools/lib
so any include with '<bpf/...> will pick up the kernel version and not the one in /usr/include, perhaps the order of '-I...' could help, I need to check
jirka
> > 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 > > >
| |