Re: [PATCH 1/1] libbpf: replace typeof with __typeof__ for -std=c17 compatibility

[Andrii Nakryiko]

On Thu, Jun 9, 2022 at 4:46 PM James Hilliard <james.hilliard1@xxxxxxxxx> wrote:
>
> On Thu, Jun 9, 2022 at 12:11 PM Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Wed, Jun 8, 2022 at 11:28 PM James Hilliard
> > <james.hilliard1@xxxxxxxxx> wrote:
> > >
> > > Fixes errors like:
> > > error: expected specifier-qualifier-list before 'typeof'
> > >    14 | #define __type(name, val) typeof(val) *name
> > >       |                           ^~~~~~
> > > ../src/core/bpf/socket_bind/socket-bind.bpf.c:25:9: note: in expansion of macro '__type'
> > >    25 |         __type(key, __u32);
> > >       |         ^~~~~~
> > >
> > > Signed-off-by: James Hilliard <james.hilliard1@xxxxxxxxx>
> > > ---
> >
> > If you follow DPDK link you gave me ([0]), you'll see that they ended up doing
> >
> > #ifndef typeof
> > #define typeof __typeof__
> > #endif
> >
> > It's way more localized. Let's do that.
>
> Won't that potentially leak the redefinition into external code including the
> header file?

all this is in BPF-side helpers and we add a bunch of other "common"
definitions like barrier(), offsetof(), etc. So I think this is
acceptable, at least for now (and users will be able to override this
due to #ifndef check, right?)

>
> I don't see a redefinition of typeof like that used elsewhere in the kernel.

kernel is just happily using much cleaner looking typeof() almost
universally, though

$ rg -w typeof ~/linux/include | wc -l
401
$ rg -w __typeof__ ~/linux/include | wc -l
28

>
> However I do see __typeof__ used in many headers already so that approach
> seems to follow normal conventions and seems less risky.
>
> FYI using -std=gnu17 instead of -std=c17 works around this issue with bpf-gcc
> at least so this issue isn't really a blocker like the SEC macro
> issue, I had just
> accidentally mixed the two issues up due to accidentally not clearing out some
> header files when testing, they seem to be entirely separate.
>
> >
> > But also I tried to build libbpf-bootstrap with -std=c17 and
> > immediately ran into issue with asm, so we need to do the same with
> > asm -> __asm__. Can you please update your patch and fix both issues?
>
> Are you hitting that with clang/llvm or bpf-gcc? It doesn't appear that the
> libbpf-bootstrap build system is set up to build with bpf-gcc yet.
>

I didn't realize you were using bpf-gcc, sorry. I was testing with clang.

> >
> >   [0] https://patches.dpdk.org/project/dpdk/patch/2601191342CEEE43887BDE71AB977258213F3012@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >   [1] https://github.com/libbpf/libbpf-bootstrap
> >
> >
> > >  tools/lib/bpf/bpf_core_read.h   | 16 ++++++++--------
> > >  tools/lib/bpf/bpf_helpers.h     |  4 ++--
> > >  tools/lib/bpf/bpf_tracing.h     | 24 ++++++++++++------------
> > >  tools/lib/bpf/btf.h             |  4 ++--
> > >  tools/lib/bpf/libbpf_internal.h |  6 +++---
> > >  tools/lib/bpf/usdt.bpf.h        |  6 +++---
> > >  tools/lib/bpf/xsk.h             | 12 ++++++------
> > >  7 files changed, 36 insertions(+), 36 deletions(-)
> > >
> >
> > [...]