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>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 4/9] libbpf: ensure btf_dump__new() and btf_dump_opts are future-proof
Date: Thu, 23 Dec 2021 14:16:09 +0100 [thread overview]
Message-ID: <YcR2mXO2/XBqueUo@krava> (raw)
In-Reply-To: <YcROEf9Ei3pUfuyF@krava>
On Thu, Dec 23, 2021 at 11:23:13AM +0100, Jiri Olsa wrote:
> On Wed, Dec 22, 2021 at 02:14:35PM -0800, Andrii Nakryiko wrote:
>
> SNIP
>
> > > > +/* Choose either btf_dump__new() or btf_dump__new_deprecated() based on the
> > > > + * type of 4th argument. If it's btf_dump's print callback, use deprecated
> > > > + * API; otherwise, choose the new btf_dump__new(). ___libbpf_override()
> > > > + * doesn't work here because both variants have 4 input arguments.
> > > > + *
> > > > + * (void *) casts are necessary to avoid compilation warnings about type
> > > > + * mismatches, because even though __builtin_choose_expr() only ever evaluates
> > > > + * one side the other side still has to satisfy type constraints (this is
> > > > + * compiler implementation limitation which might be lifted eventually,
> > > > + * according to the documentation). So passing struct btf_ext in place of
> > > > + * btf_dump_printf_fn_t would be generating compilation warning. Casting to
> > > > + * void * avoids this issue.
> > > > + *
> > > > + * Also, two type compatibility checks for a function and function pointer are
> > > > + * required because passing function reference into btf_dump__new() as
> > > > + * btf_dump__new(..., my_callback, ...) and as btf_dump__new(...,
> > > > + * &my_callback, ...) (not explicit ampersand in the latter case) actually
> > > > + * differs as far as __builtin_types_compatible_p() is concerned. Thus two
> > > > + * checks are combined to detect callback argument.
> > > > + *
> > > > + * The rest works just like in case of ___libbpf_override() usage with symbol
> > > > + * versioning.
> > > > + */
> > > > +#define btf_dump__new(a1, a2, a3, a4) __builtin_choose_expr( \
> > > > + __builtin_types_compatible_p(typeof(a4), btf_dump_printf_fn_t) || \
> > > > + __builtin_types_compatible_p(typeof(a4), void(void *, const char *, va_list)), \
> > > > + btf_dump__new_deprecated((void *)a1, (void *)a2, (void *)a3, (void *)a4), \
> > > > + btf_dump__new((void *)a1, (void *)a2, (void *)a3, (void *)a4))
> > >
> > > hi,
> > > this change breaks bpftrace g++ build that includes btf.h,
> > > because there's no typeof and __builtin_types_compatible_p in c++
> > >
> > > I guess there could be some c++ solution doing similar check,
> > > but I wonder we want to polute btf.h with that, I'll need to
> > > check on that
> > >
> > > I think I can add some detection code to bpftrace, to find out
> > > which version of btf_dump__new to use
> > >
> > > the build error can be generated with test_cpp.cpp below,
> > > so far I'm using __cplusplus ifdef in btf.h to workaround
> > > the issue
> > >
> > > thoughts?
> >
> > This has been reported before, see [0]. I think the simplest solution
> > is what you did, just to opt-out on __cplusplus.
> >
> > Please send the below as a proper two patches and I'll apply them and
> > sync to Github. Also let's add a comment explaining that
> > __builtin_types_compatible_p doesn't work with C++ compiler to make it
> > clear why we do this.
>
> ok, will send
I see you've already provided the same patch in the github comment,
so I'll put your Signed-off-by in the patch as well
jirka
>
> thanks,
> jirka
>
> >
> > In the [0] I was proposing the following comment, feel free to reuse it.
> >
> > /* C++ compilers don't support __builtin_types_compatible_p(), so at least
> > * don't screw up compilation for them and let C++ users pick btf_dump__new vs
> > * btf_dump__new_deprecated explicitly.
> > */
> >
> > [0] https://github.com/libbpf/libbpf/issues/283#issuecomment-986100727
> >
> > >
> > > thanks,
> > > jirka
> > >
> > >
> > > ---
> > > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > > index 742a2bf71c5e..bd2d77979571 100644
> > > --- a/tools/lib/bpf/btf.h
> > > +++ b/tools/lib/bpf/btf.h
> > > @@ -314,11 +314,13 @@ LIBBPF_API struct btf_dump *btf_dump__new_deprecated(const struct btf *btf,
> > > * The rest works just like in case of ___libbpf_override() usage with symbol
> > > * versioning.
> > > */
> > > +#ifndef __cplusplus
> > > #define btf_dump__new(a1, a2, a3, a4) __builtin_choose_expr( \
> > > __builtin_types_compatible_p(typeof(a4), btf_dump_printf_fn_t) || \
> > > __builtin_types_compatible_p(typeof(a4), void(void *, const char *, va_list)), \
> > > btf_dump__new_deprecated((void *)a1, (void *)a2, (void *)a3, (void *)a4), \
> > > btf_dump__new((void *)a1, (void *)a2, (void *)a3, (void *)a4))
> > > +#endif
> > >
> > > LIBBPF_API void btf_dump__free(struct btf_dump *d);
> > >
> > > diff --git a/tools/testing/selftests/bpf/test_cpp.cpp b/tools/testing/selftests/bpf/test_cpp.cpp
> > > index a8d2e9a87fbf..e00201de2890 100644
> > > --- a/tools/testing/selftests/bpf/test_cpp.cpp
> > > +++ b/tools/testing/selftests/bpf/test_cpp.cpp
> > > @@ -7,9 +7,15 @@
> > >
> > > /* do nothing, just make sure we can link successfully */
> > >
> > > +static void dump_printf(void *ctx, const char *fmt, va_list args)
> > > +{
> > > +}
> > > +
> > > int main(int argc, char *argv[])
> > > {
> > > + struct btf_dump_opts opts = { };
> > > struct test_core_extern *skel;
> > > + struct btf *btf;
> > >
> > > /* libbpf.h */
> > > libbpf_set_print(NULL);
> > > @@ -18,7 +24,8 @@ int main(int argc, char *argv[])
> > > bpf_prog_get_fd_by_id(0);
> > >
> > > /* btf.h */
> > > - btf__new(NULL, 0);
> > > + btf = btf__new(NULL, 0);
> > > + btf_dump__new(btf, dump_printf, nullptr, &opts);
> > >
> > > /* BPF skeleton */
> > > skel = test_core_extern__open_and_load();
> > >
> >
next prev parent reply other threads:[~2021-12-23 13:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 5:36 [PATCH v2 bpf-next 0/9] Future-proof more tricky libbpf APIs Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 1/9] bpftool: normalize compile rules to specify output file last Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 2/9] selftests/bpf: minor cleanups and normalization of Makefile Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 3/9] libbpf: turn btf_dedup_opts into OPTS-based struct Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 4/9] libbpf: ensure btf_dump__new() and btf_dump_opts are future-proof Andrii Nakryiko
2021-12-22 14:55 ` Jiri Olsa
2021-12-22 22:14 ` Andrii Nakryiko
2021-12-23 10:23 ` Jiri Olsa
2021-12-23 13:16 ` Jiri Olsa [this message]
2021-11-11 5:36 ` [PATCH v2 bpf-next 5/9] libbpf: make perf_buffer__new() use OPTS-based interface Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 6/9] selftests/bpf: migrate all deprecated perf_buffer uses Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 7/9] selftests/bpf: update btf_dump__new() uses to v1.0+ variant Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 8/9] tools/runqslower: update perf_buffer__new() calls Andrii Nakryiko
2021-11-11 5:36 ` [PATCH v2 bpf-next 9/9] bpftool: update btf_dump__new() and perf_buffer__new_raw() calls Andrii Nakryiko
2021-11-12 0:59 ` [PATCH v2 bpf-next 0/9] Future-proof more tricky libbpf APIs Alexei Starovoitov
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=YcR2mXO2/XBqueUo@krava \
--to=jolsa@redhat.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.