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(-) > > > > > > > [...]
