> On 17/10/25 00:20, David Faust wrote: >> On 10/12/25 21:26, Piyush Raj wrote: >>> This patch adds new DejaGnu target board for BPF for runtime testing of >>> BPF programs using the `bpf-vmtest-tool` script in the contrib directory. >>> The kernel version used for the tests can be specified via KERNEL_VERSION, >>> for example: >>> make check-gcc RUNTESTFLAGS="--target_board=bpf bpf-torture.exp >>> KERNEL_VERSION=6.14" >>> >>> If not specified, the default kernel version used is 6.15. >>> >>> It also adds a new torture subdirectory for running torture tests on BPF >>> programs. >>> Passed tests covered in bpf.exp and bpf-torture.exp >> I noticed that depending on the local vmlinux.h, we may get some >> extraneous >> "excess error" FAILs originating from warnings like with -Wattributes >> in vmlinux.h. I think we could also potentially end up with things like >> #pragmas that are specific to clang in vmlinux.h or elsewhere, depending >> on where those files are coming from. >> > I didn’t encounter this issue while developing on 6.15, but after > upgrading to 6.16 and regenerating my vmlinux.h, I ran into the issue > you described. > In my case, it was triggered by a single attribute: > > /usr/local/include/vmlinux.h:161258:1: warning: 'btf_type_tag' > attribute directive ignored [-Wattributes] > > >> I'm not sure what is the best way to deal with that for this testsuite. >> Disabling -Wattributes doesn't seem ideal, but neither does annotating >> each individual test #including vmlinux.h to suppress the warning... >> Opinions/thoughts anyone? >> (I don't think this should be a blocker, but it would be nice to >> deal >> with it somehow.) >> > > Are the attributes that GCC is warning about actually required by GCC > to compile the program correctly, or are they something that needs to > be implemented in the backend? If it’s the latter, I don’t think > ignoring them for a testcase is ideal. > > For btf_type_tag, it seems to be the latter case (see: > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673841.html) > > Should we consider including the testcases for features that haven’t > been implemented yet, but maintain a denylist similar to what BPF CI > does for GCC?
I think we definitely want to know whether our own testscases raise some particular warning when using the headers of some particular kernel. So FWIW I wouldn't inhibit these warnings. IMO these are a good reminder (and incentive) that we gotta deal with the situation in some way, be it fix the kernel headers, or bpftool that generates them, or implementing whatever feature is missing in GCC. > See: > https://github.com/kernel-patches/vmtest/blob/master/ci/vmtest/configs/DENYLIST.test_progs-bpf_gcc > Would this approach be useful?
