Hello everyone.
I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
originally done by Cupertino Miranda [2].
I encountered issues compiling BPF objects for selftests/bpf with
recent GCC 15 snapshots. An additional test runner binary is supposed
to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
set to a directory with GCC binaries for BPF backend. The runner
binary depends on BPF binaries, which are produced by GCC.
The first issue is compilation errors on vmlinux.h:
In file included from progs/linked_maps1.c:4:
/ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
error: expected identifier before ‘false’
8483 | false = 0,
| ^~~~~
A snippet from vmlinux.h:
enum {
false = 0,
true = 1,
};
And:
/ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
error: two or more data types in declaration specifiers
23539 | typedef _Bool bool;
| ^~~~
Full log at [3], and also at [4].
You can easily reproduce the errors with a dummy program:
#include "vmlinux.h"
int main() {
return 0;
}
The vmlinux.h is generated from BTF, produced by pahole v1.28 from
DWARF data contained in the vmlinux binary. The vmlinux binary I used
in these experiments is v6.12 (adc218676eef) compiled with gcc 13.3.0
(default Ubuntu installation).
You can download the specific vmlinux.h I tried using a link below [5].
I bisected recent GCC snapshots and determined that the errors related
to the bool declarations started happening on GCC 15-20241117.
Older versions compile the dummy program without errors, however on
attempt to build the selftests there is a different issue: conflicting
int64 definitions (full log at [6]).
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
from /usr/include/x86_64-linux-gnu/bits/socket.h:29,
from /usr/include/x86_64-linux-gnu/sys/socket.h:33,
from /usr/include/linux/if.h:28,
from /usr/include/linux/icmp.h:23,
from progs/test_cls_redirect_dynptr.c:10:
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error: conflicting
types for ‘int64_t’; have ‘__int64_t’ {aka ‘long long int’}
27 | typedef __int64_t int64_t;
| ^~~~~~~
In file included from progs/test_cls_redirect_dynptr.c:6:
/ci/workspace/bpfgcc.20240922/lib/gcc/bpf-unknown-none/15.0.0/include/stdint.h:43:24:
note: previous declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
43 | typedef __INT64_TYPE__ int64_t;
| ^~~~~~~
This is on a typical ubuntu:noble system:
$ dpkg -s libc6 | grep Version
Version: 2.39-0ubuntu8.3
I got this with snapshots 15-20241110 and 15-20240922 (the oldest I
tested). This problem may or may not be present in the most recent
versions, I can't tell for sure.
GCC team, please investigate and let me know if you're aware of
workarounds or if there is a specific GCC version that you know is
capable of building BPF programs in selftests/bpf.
If you suspect something might be wrong with the includes for BPF
programs, or GCC snapshot build etc, please also let me know. I mostly
relied on Cupertino scripts when setting that up, and assumed the
selftests/bpf/Makefile is handling BPF_GCC correctly.
Thank you, and happy holidays!
[1] https://github.com/libbpf/ci/pull/164
[2] https://github.com/libbpf/ci/pull/144
[3] https://gist.github.com/theihor/98883c4266b3489cee69e5d5aa532e79
[4] https://github.com/libbpf/ci/actions/runs/12522053128/job/34929897322
[5] https://gist.github.com/theihor/785bb250dd1cce3612e70b5f6d258401
[6] https://gist.github.com/theihor/a8aa7201b30ac6b48df77bb1ea3ec0b2
