From: Björn Töpel <bjorn@kernel.org> Date: 2023-02-10 08:43:40
From: Björn Töpel <redacted>
When the BPF selftests are cross-compiled, only the a host version of
bpftool is built. This version of bpftool is used to generate various
intermediates, e.g., skeletons.
The test runners are also using bpftool. The Makefile will symlink
bpftool from the selftest/bpf root, where the test runners will look
for the tool:
| ...
| $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/bootstrap/bpftool \
| $(OUTPUT)/$(if $2,$2/)bpftool
There are two issues for cross-compilation builds:
1. There is no native (cross-compilation target) build of bpftool
2. The bootstrap variant of bpftool is never cross-compiled (by
design)
Make sure that a native/cross-compiled version of bpftool is built,
and if CROSS_COMPILE is set, symlink to the native/non-bootstrap
version.
Signed-off-by: Björn Töpel <redacted>
---
tools/testing/selftests/bpf/Makefile | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
From: Björn Töpel <bjorn@kernel.org> Date: 2023-02-13 14:30:58
Björn Töpel [off-list ref] writes:
From: Björn Töpel <redacted>
When the BPF selftests are cross-compiled, only the a host version of
bpftool is built. This version of bpftool is used to generate various
intermediates, e.g., skeletons.
The test runners are also using bpftool. The Makefile will symlink
bpftool from the selftest/bpf root, where the test runners will look
for the tool:
| ...
| $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/bootstrap/bpftool \
| $(OUTPUT)/$(if $2,$2/)bpftool
There are two issues for cross-compilation builds:
1. There is no native (cross-compilation target) build of bpftool
2. The bootstrap variant of bpftool is never cross-compiled (by
design)
Make sure that a native/cross-compiled version of bpftool is built,
and if CROSS_COMPILE is set, symlink to the native/non-bootstrap
version.
...and the grand master plan is to add BPF CI support for riscv64, where
this patch a prerequisite to [1]. I would suspect that other platforms
might benefit from cross-compilation builds as well.
[1] https://github.com/kernel-patches/vmtest/pull/194
2023-02-10 09:43 UTC+0100 ~ Björn Töpel [off-list ref]
quoted hunk
From: Björn Töpel <redacted>
When the BPF selftests are cross-compiled, only the a host version of
bpftool is built. This version of bpftool is used to generate various
intermediates, e.g., skeletons.
The test runners are also using bpftool. The Makefile will symlink
bpftool from the selftest/bpf root, where the test runners will look
for the tool:
| ...
| $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/bootstrap/bpftool \
| $(OUTPUT)/$(if $2,$2/)bpftool
There are two issues for cross-compilation builds:
1. There is no native (cross-compilation target) build of bpftool
2. The bootstrap variant of bpftool is never cross-compiled (by
design)
Make sure that a native/cross-compiled version of bpftool is built,
and if CROSS_COMPILE is set, symlink to the native/non-bootstrap
version.
Signed-off-by: Björn Töpel <redacted>
---
tools/testing/selftests/bpf/Makefile | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
The changes look good to me, thanks!
Acked-by: Quentin Monnet <redacted>
Jean-Philippe, I know you do some cross-compiling with bpftool, how does
this look from your side?
Hi Bjorn,
Thanks for the patch, I've tested it and it works for me.
I have a minor suggestion but otherwise happy to see this getting fixed.
On 10/02/2023 08:43, Björn Töpel wrote:
quoted hunk
From: Björn Töpel <redacted>
When the BPF selftests are cross-compiled, only the a host version of
bpftool is built. This version of bpftool is used to generate various
intermediates, e.g., skeletons.
The test runners are also using bpftool. The Makefile will symlink
bpftool from the selftest/bpf root, where the test runners will look
for the tool:
| ...
| $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/bootstrap/bpftool \
| $(OUTPUT)/$(if $2,$2/)bpftool
There are two issues for cross-compilation builds:
1. There is no native (cross-compilation target) build of bpftool
2. The bootstrap variant of bpftool is never cross-compiled (by
design)
Make sure that a native/cross-compiled version of bpftool is built,
and if CROSS_COMPILE is set, symlink to the native/non-bootstrap
version.
Signed-off-by: Björn Töpel <redacted>
---
tools/testing/selftests/bpf/Makefile | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
...
-TEST_GEN_PROGS_EXTENDED += $(DEFAULT_BPFTOOL)
+TEST_GEN_PROGS_EXTENDED += $(TRUNNER_BPFTOOL)
Ensure the target arch bpftool is copied into the kselftest_bpf_install
dir by selftests/lib.mk instead of always the default/host version.
Thanks,
Zach
From: Björn Töpel <redacted>
When the BPF selftests are cross-compiled, only the a host version of
bpftool is built. This version of bpftool is used to generate various
intermediates, e.g., skeletons.
The test runners are also using bpftool. The Makefile will symlink
bpftool from the selftest/bpf root, where the test runners will look
for the tool:
| ...
| $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/bootstrap/bpftool \
| $(OUTPUT)/$(if $2,$2/)bpftool
There are two issues for cross-compilation builds:
1. There is no native (cross-compilation target) build of bpftool
2. The bootstrap variant of bpftool is never cross-compiled (by
design)
Make sure that a native/cross-compiled version of bpftool is built,
and if CROSS_COMPILE is set, symlink to the native/non-bootstrap
version.
...and the grand master plan is to add BPF CI support for riscv64, where
this patch a prerequisite to [1]. I would suspect that other platforms
might benefit from cross-compilation builds as well.
Similar use case. There also seems to be a lot of issues building these
tests out of tree.
I have some potential fixes up to 6.1 but linux-next seems to have
introduced a few more issues on top.
From: Björn Töpel <bjorn@kernel.org> Date: 2023-02-14 09:41:13
Zachary Leaf [off-list ref] writes:
Hi Bjorn,
Thanks for the patch, I've tested it and it works for me.
Good!
I have a minor suggestion but otherwise happy to see this getting fixed.
...
-TEST_GEN_PROGS_EXTENDED += $(DEFAULT_BPFTOOL)
+TEST_GEN_PROGS_EXTENDED += $(TRUNNER_BPFTOOL)
Ensure the target arch bpftool is copied into the kselftest_bpf_install
dir by selftests/lib.mk instead of always the default/host version.
Good one. I'll spin a v2, and also fix Quentin's "double-slash".
Björn
From: Björn Töpel <bjorn@kernel.org> Date: 2023-02-14 09:44:40
Zachary Leaf [off-list ref] writes:
On 13/02/2023 14:30, Björn Töpel wrote:
quoted
Björn Töpel [off-list ref] writes:
quoted
From: Björn Töpel <redacted>
When the BPF selftests are cross-compiled, only the a host version of
bpftool is built. This version of bpftool is used to generate various
intermediates, e.g., skeletons.
The test runners are also using bpftool. The Makefile will symlink
bpftool from the selftest/bpf root, where the test runners will look
for the tool:
| ...
| $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/bootstrap/bpftool \
| $(OUTPUT)/$(if $2,$2/)bpftool
There are two issues for cross-compilation builds:
1. There is no native (cross-compilation target) build of bpftool
2. The bootstrap variant of bpftool is never cross-compiled (by
design)
Make sure that a native/cross-compiled version of bpftool is built,
and if CROSS_COMPILE is set, symlink to the native/non-bootstrap
version.
...and the grand master plan is to add BPF CI support for riscv64, where
this patch a prerequisite to [1]. I would suspect that other platforms
might benefit from cross-compilation builds as well.
Similar use case. There also seems to be a lot of issues building these
tests out of tree.
I have some potential fixes up to 6.1 but linux-next seems to have
introduced a few more issues on top.
Ah, yes. FWIW, the BPF CI builds the selftests *in-tree*, so with this
patch (and my PRs) the BPF CI is capable of cross-compiling.
Björn