Mark Brown <broonie@xxxxxxxxxx> writes: > On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote: > >> When building the kselftest suite, e.g.: > >> make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \ >> SKIP_TARGETS="" O=/output/foo -C tools/testing/selftests install > >> The expectation is that the sched_ext is included, cross-built, and >> placed into /output/foo. > > When building for arm64 with this applied on top of mainline or -next > I'm seeing: Thanks for taking it for a spin! > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/testing/selftests TARGETS=sched_ext SKIP_TARGETS=" > > give > > CLNG-BPF create_dsq.bpf.o > In file included from create_dsq.bpf.c:9: > /home/broonie/git/linux/tools/sched_ext/include/scx/common.bpf.h:33:17: error: use of undeclared identifier 'SCX_DSQ_FLAG_BUILTIN' > 33 | _Static_assert(SCX_DSQ_FLAG_BUILTIN, > | ^ This is most likely due to incorrect VMLINUX_BTF_PATHS, so that vmlinux.h is incorrectly generated. Try grepping for SCX_DSQ_FLAG_BUILTIN in vmlinux.h. > and more (my system clang is clang 20). It's also failing with a native > x86_64 build in the same way. I've run "make headers_install", it looks > like clang is not getting told about the copy of the headers installed > in ./usr/include: > > clang -g -D__TARGET_ARCH_x86 -mlittle-endian -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/include -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/include/bpf-compat -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/build/include -I/home/broonie/git/linux/tools/include/uapi -I/home/broonie/git/linux/tools/sched_ext/include -I/home/broonie/git/linux/include -idirafter /usr/lib/llvm-20/lib/clang/20/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -Wall -Wno-compare-distinct-pointer-types -Wno-incompatible-function-pointer-types -O2 -mcpu=v3 -target bpf -c create_dsq.bpf.c -o /home/broonie/git/linux/tools/testing/selftests/sched_ext/build/obj/sched_ext/create_dsq.bpf.o The sched_ext BPF programs relies on a vmlinux.h, which is generated using bpftool and the vmlinux with BTF information. Have you built a kernel with BTF support? >> Add CROSS_COMPILE, OUTPUT, and TARGETS support to the sched_ext >> selftest. Also, remove some variables that were unused by the >> Makefile. > >> +ifneq ($(CROSS_COMPILE),) >> +DEFAULT_BPFTOOL := $(OUTPUT_DIR)/host/sbin/bpftool >> +HOST_OBJ_DIR := $(OBJ_DIR)/host/bpftool >> +HOST_LIBBPF_OUTPUT := $(OBJ_DIR)/host/libbpf/ >> +HOST_LIBBPF_DESTDIR := $(OUTPUT_DIR)/host/ >> +HOST_DESTDIR := $(OUTPUT_DIR)/host/ >> +else >> +DEFAULT_BPFTOOL := $(OUTPUT_DIR)/sbin/bpftool >> +HOST_OBJ_DIR := $(OBJ_DIR)/bpftool >> +HOST_LIBBPF_OUTPUT := $(OBJ_DIR)/libbpf/ >> +HOST_LIBBPF_DESTDIR := $(OUTPUT_DIR)/ >> +HOST_DESTDIR := $(OUTPUT_DIR)/ >> +endif > > This won't detect a cross compile when building using LLVM as that > doesn't need to set CROSS_COMPILE, it can use the same binaries for all > targets. There's runes in the Makefile for the mm selftests for > identifying the target architecture, though actually I'm wondering if > it's worth just always building the host copy and never having to worry > if the target build is a cross build or not? It's obvious overhead in > the native case though if we actually need the target copy. Yeah, that would indeed simplify things! I'll spin a v3 with that (and wait for more feedback). Thanks for testing the patch! Björn
