From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Ihor Solodrai <ihor.solodrai@pm.me>
Cc: bpf <bpf@vger.kernel.org>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
Cupertino Miranda <cupertino.miranda@oracle.com>,
David Faust <david.faust@oracle.com>,
Elena Zannoni <elena.zannoni@oracle.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Manu Bretelle <chantra@meta.com>,
Eduard Zingerman <eddyz87@gmail.com>,
Mykola Lysenko <mykolal@meta.com>,
Yonghong Song <yonghong.song@linux.dev>,
Andrew Pinski <pinskia@gmail.com>, Sam James <sam@gentoo.org>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
Date: Sat, 04 Jan 2025 09:05:42 +0100 [thread overview]
Message-ID: <87pll3c8bt.fsf@oracle.com> (raw)
In-Reply-To: <EYcXjcKDCJY7Yb0GGtAAb7nLKPEvrgWdvWpuNzXm2qi6rYMZDixKv5KwfVVMBq17V55xyC-A1wIjrqG3aw-Imqudo9q9X7D7nLU2gWgbN0w=@pm.me> (Ihor Solodrai's message of "Fri, 03 Jan 2025 23:48:52 +0000")
> Hi everyone.
>
> I built and ran selftests/bpf with GCC 15-20241229, and would like to
> share my findings.
>
> Building required small adjustments in the Makefile, besides -std=gnu17
>
> With the following change we can mitigate int64_t issue:
>
> +progs/test_cls_redirect.c-CFLAGS := -nostdinc
> +progs/test_cls_redirect_dynptr.c-CFLAGS := -nostdinc
> +progs/test_cls_redirect_subprogs.c-CFLAGS := -nostdinc
These shouldn' be necessary anymore after the change in
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672508.html
> Then, the compiler complains about an uninitialized variable in
> progs/verifier_bpf_fastcall.c and progs/verifier_search_pruning.c
> (full log at [1]):
>
> In file included from progs/verifier_bpf_fastcall.c:7:
> progs/verifier_bpf_fastcall.c: In function ‘may_goto_interaction’:
> progs/bpf_misc.h:153:42: error: ‘<Uc098>’ is used uninitialized [-Werror=uninitialized]
> 153 | #define __imm_insn(name, expr) [name]"i"(*(long *)&(expr))
> | ^~~~~~~~~~~~~~~~
> progs/verifier_bpf_fastcall.c:652:11: note: in expansion of macro ‘__imm_insn’
> 652 | __imm_insn(may_goto, BPF_RAW_INSN(BPF_JMP | BPF_JCOND, 0, 0, +1 /* offset */, 0))
> | ^~~~~~~~~~
> /ci/workspace/tools/testing/selftests/bpf/../../../include/linux/filter.h:299:28:
> note: ‘({anonymous})’ declared here
> 299 | ((struct bpf_insn) { \
> | ^
> progs/bpf_misc.h:153:53: note: in definition of macro ‘__imm_insn’
> 153 | #define __imm_insn(name, expr) [name]"i"(*(long *)&(expr))
> | ^~~~
> progs/verifier_bpf_fastcall.c:652:32: note: in expansion of macro ‘BPF_RAW_INSN’
> 652 | __imm_insn(may_goto, BPF_RAW_INSN(BPF_JMP | BPF_JCOND, 0, 0, +1 /* offset */, 0))
>
> BPF_RAW_INSN expands into struct init expr (include/linux/filter.h):
>
> #define BPF_RAW_INSN(CODE, DST, SRC, OFF, IMM) \
> ((struct bpf_insn) { \
> .code = CODE, \
> .dst_reg = DST, \
> .src_reg = SRC, \
> .off = OFF, \
> .imm = IMM })
>
> This can be silenced with:
>
> +progs/verifier_bpf_fastcall.c-CFLAGS := -Wno-error
> +progs/verifier_search_pruning.c-CFLAGS := -Wno-error
Ignoring the warning doesn't cure the resulting undefined behavior.
These selftests seems to be violating strict aliasing rules, so it is
better to either change the testcase to work well with anti-aliasing
rules or to disable strict aliasing, like it is done for many other
tests already:
progs/verifier_bpf_fastcall.c-CFLAGS := -fno-strict-aliasing
progs/verifier_search_pruning.c-CFLAGS := -fno-strict-aliasing
> Then the selftests/bpf build completes successfully, although libbpf
> prints a lot of warnings like these on GEN-SKEL:
>
> [...]
> libbpf: elf: skipping section(3) .data (size 0)
> libbpf: elf: skipping section(4) .data (size 0)
> libbpf: elf: skipping unrecognized data section(13) .comment
> libbpf: elf: skipping unrecognized data section(9) .comment
> libbpf: elf: skipping unrecognized data section(12) .comment
> libbpf: elf: skipping unrecognized data section(7) .comment
> [...]
>
> Test .bpf.o files are compiled regardless. Full log at [2].
>
> Running all tests at once, as is usually done on CI, produces a too
> cluttered log. I wrote a script to run each test individually in a
> separate qemu instance and collect the logs.
>
> 187/581 of toplevel tests fail on current bpf-next [3]. Many tests
> have subtests: toplevel test passes if all of its subtests pass.
Thanks for the report.
>
> You can find the archive with per-test logs at [4].
>
> [1] https://gist.github.com/theihor/10b2425e6780fcfebb80aeceafba7678
> [2] https://gist.github.com/theihor/9e96643ca730365cf79cea8445e40aeb
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=96ea081ed52bf077cad6d00153b6fba68e510767
> [4] https://github.com/kernel-patches/bpf/blob/8f2e62702ee17675464ab00d97d89d599922de20/tools/testing/selftests/bpf/gcc-bpf-selftests-logs.tgz
prev parent reply other threads:[~2025-01-04 8:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 20:08 Errors compiling BPF programs from Linux selftests/bpf with GCC Ihor Solodrai
2024-12-30 20:24 ` Andrew Pinski
2024-12-30 20:36 ` Sam James
2024-12-30 20:59 ` Ihor Solodrai
2024-12-30 21:08 ` Sam James
2024-12-31 0:42 ` Alexei Starovoitov
2024-12-31 1:26 ` Ihor Solodrai
2024-12-31 4:09 ` Alexei Starovoitov
2025-01-02 9:47 ` Jose E. Marchesi
2025-01-02 17:35 ` Ihor Solodrai
2025-01-02 18:24 ` Jose E. Marchesi
2025-01-03 0:42 ` Eduard Zingerman
2025-01-03 13:23 ` Jose E. Marchesi
2025-01-02 23:04 ` Eduard Zingerman
2025-01-03 0:16 ` Jose E. Marchesi
2025-01-03 0:46 ` Eduard Zingerman
2025-01-03 10:17 ` Jose E. Marchesi
2025-01-03 12:52 ` Jose E. Marchesi
2025-01-03 23:48 ` Ihor Solodrai
2025-01-03 23:56 ` Andrew Pinski
2025-01-04 8:05 ` Jose E. Marchesi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pll3c8bt.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chantra@meta.com \
--cc=cupertino.miranda@oracle.com \
--cc=david.faust@oracle.com \
--cc=eddyz87@gmail.com \
--cc=elena.zannoni@oracle.com \
--cc=gcc@gcc.gnu.org \
--cc=ihor.solodrai@pm.me \
--cc=mykolal@meta.com \
--cc=pinskia@gmail.com \
--cc=sam@gentoo.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox