[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvTj4oBy3nP3s2BaN_+75dYfkq2x72wG3dC3K09osRzkcw2eA@mail.gmail.com>
Date: Thu, 9 Jun 2022 17:46:13 -0600
From: James Hilliard <james.hilliard1@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Björn Töpel <bjorn@...nel.org>,
Magnus Karlsson <magnus.karlsson@...el.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
Jonathan Lemon <jonathan.lemon@...il.com>,
"open list:BPF (Safe dynamic programs and tools)"
<netdev@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] libbpf: replace typeof with __typeof__ for -std=c17 compatibility
On Thu, Jun 9, 2022 at 12:11 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Wed, Jun 8, 2022 at 11:28 PM James Hilliard
> <james.hilliard1@...il.com> 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@...il.com>
> > ---
>
> 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?
I don't see a redefinition of typeof like that used elsewhere in the kernel.
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.
>
> [0] https://patches.dpdk.org/project/dpdk/patch/2601191342CEEE43887BDE71AB977258213F3012@irsmsx105.ger.corp.intel.com/
> [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(-)
> >
>
> [...]
Powered by blists - more mailing lists