Re: Announcement: GCC BPF is now being tested on BPF CI

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

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@gcc.gnu.org would be the default point of
> contact, but if there are specific people who should be notified
> please let me know.