On Tue, 15 Nov 2022 at 13:36, Björn Töpel bjorn@kernel.org wrote:
Hi,
Adding the kselftest list
I ran into build issues when building selftests/net on Ubuntu/Debian, which is related to that BPF program builds usually needs libc (and the corresponding target host configuration/defines).
When I try to build selftests/net, on my Debian host I get:
I've ran into this issue too building with tuxmake [1] that uses debian containers.
clang -O2 -target bpf -c bpf/nat6to4.c -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o In file included from bpf/nat6to4.c:27: In file included from /usr/include/linux/bpf.h:11: /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found #include <asm/types.h> ^~~~~~~~~~~~~ 1 error generated.
asm/types.h lives in /usr/include/"TRIPLE" on Debian, say /usr/include/x86_64-linux-gnu. Target BPF does not (obviously) add the x86-64 search path. These kind of problems have been worked around in, e.g., commit 167381f3eac0 ("selftests/bpf: Makefile fix "missing" headers on build with -idirafter").
However, just adding the host specific path is not enough. Typically, when you start to include libc files, like "sys/socket.h" it's expected that host specific defines are set. On my x86-64 host:
$ clang -dM -E - < /dev/null|grep x86_ #define __x86_64 1 #define __x86_64__ 1
$ clang -target riscv64-linux-gnu -dM -E - < /dev/null|grep xlen #define __riscv_xlen 64
otherwise you end up with errors like the one below.
Missing __x86_64__: #if !defined __x86_64__ # include <gnu/stubs-32.h> #endif
clang -O2 -target bpf -c bpf/nat6to4.c -idirafter /usr/lib/llvm-16/lib/clang/16.0.0/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -Wno-compare-distinct-pointer-types -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o In file included from bpf/nat6to4.c:28: In file included from /usr/include/linux/if.h:28: In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:22: In file included from /usr/include/features.h:510: /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found # include <gnu/stubs-32.h> ^~~~~~~~~~~~~~~~ 1 error generated.
Now, say that we'd like to cross-compile for a platform. Should I make sure that all the target compiler's "default defines" are exported to the BPF-program build step? I did a hack for RISC-V a while back in commit 6016df8fe874 ("selftests/bpf: Fix broken riscv build"). Not super robust, and not something I'd like to see for all supported platforms.
Any ideas? Maybe a convenience switch to Clang/target bpf? :-)
I added the same thing selftests/bpf have in their Makefile [2] and that highlighted another issue which is that selftests/net/bpf depends on bpf_helpers.h which in turn depends on the generated file bpf_helper_defs.h...
Cheers, Anders [1] https://tuxmake.org/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...