I remind that just as bad as the decl_tags it also misses a solution to
the attribute ((preserve_access_index)).
Something like #pragma clang push/pop is not viable in GCC.
Jose proposed the patch in:
https://lore.kernel.org/bpf/20240503111836.25275-1-jose.marchesi@xxxxxxxxxx/
Maybe you could accept his patch in the meanwhile, and work on the
intended improvements later. It would be passing more tests then roughly
half.
Thanks
Thank you for getting this up and running!
Hi everyone.
GCC BPF support in BPF CI has been landed.
The BPF CI dashboard is here:
https://github.com/kernel-patches/bpf/actions/workflows/test.yml
A summary of what happens on CI (relevant to GCC BPF):
* Linux Kernel is built on a target source revision
* Latest snapshots of GCC 15 and binutils are downloaded
* GCC BPF compiler is built and cached
* selftests/bpf test runners are built with BPF_GCC variable set
* BPF_GCC triggers a build of test_progs-bpf_gcc runner
* The runner contains BPF binaries produced by GCC BPF
* In a separate job, test_progs-bpf_gcc is executed within qemu
against the target kernel
GCC BPF is only tested on x86_64.
On x86_64 we test the following toolchains for building the kernel and
test runners: gcc-13 (ubuntu 24 default), clang-17, clang-18.
An example of successful test run (you have to login to github to see
the logs):
https://github.com/kernel-patches/bpf/actions/runs/12816136141/job/35736973856
Currently 2513 of 4340 tests pass for GCC BPF, so a bit more than a half.
Effective BPF selftests denylist for GCC BPF is located here:
https://github.com/kernel-patches/vmtest/blob/master/ci/vmtest/configs/DENYLIST.test_progs-bpf_gcc
When a patch is submitted to BPF, normally a corresponding PR for
kernel-patches/bpf github repo is automatically created to trigger a
BPF CI run for this change. PRs opened manually will do that too, and
this can be used to test patches before submission.
Since the CI automatically pulls latest GCC snapshot, a change in GCC
can potentially cause CI failures unrelated to Linux changes being
tested. This is not the only dependency like that, of course.
In such situations, a change is usually made in CI code to mitigate
the failure in order to unblock the pipeline for patches. If that
happens with GCC, someone (most likely me) will have to reach out to
GCC team. I guess gcc@xxxxxxxxxxx would be the default point of
contact, but if there are specific people who should be notified
please let me know.
