When trying to build the latest BPF selftests, with a debug kernel config, Pahole 1.30 and CLang 20.1.8 (and GCC 15.2), I got these errors:
progs/dynptr_success.c:579:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ progs/dynptr_success.c:579:9: note: did you mean 'bpf_dynptr_size'? .virtme/build-debug-btf//tools/include/vmlinux.h:120280:14: note: 'bpf_dynptr_size' declared here 120280 | extern __u32 bpf_dynptr_size(const struct bpf_dynptr *p) __weak __ksym; | ^ progs/dynptr_success.c:579:7: error: incompatible integer to pointer conversion assigning to '__u64 *' (aka 'unsigned long long *') from 'int' [-Wint-conversion] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ progs/dynptr_success.c:596:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ progs/dynptr_success.c:596:7: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't have these errors without the debug kernel config from kernel/configs/debug.config. With the debug kernel, bpf_dynptr_slice() is not declared in vmlinux.h. It is declared there without debug.config.
The fix is similar to what is done in dynptr_fail.c which is also using bpf_dynptr_slice(): bpf_kfuncs.h is now included.
Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org --- Notes: - This patch looks wrong, I guess bpf_dynptr_slice() should be in vmlinux.h even with a "debug" kernel, but it is not: $ grep -cw bpf_dynptr_slice .virtme/build-debug-btf/tools/include/vmlinux.h 0 $ grep -w bpf_dynptr_slice .virtme/build-btf/tools/include/vmlinux.h extern void *bpf_dynptr_slice(...) __weak __ksym; - This is on top of bpf/master: commit 63d2247e2e37, tag bpf-fixes. - I only see this error when using kernel/configs/debug.config. - Because this has not been spot by the BPF CI, I wonder if I'm building the BPF selftests properly... Here is what I did: $ virtme-configkernel --arch x86_64 --defconfig \ --custom tools/testing/selftests/net/mptcp/config \ --custom kernel/configs/debug.config \ --custom tools/testing/selftests/bpf/config \ O=${PWD}/.virtme/build-debug-btf $ ./scripts/config --file ${PWD}/.virtme/build-debug-btf/.config \ -e NET_NS_REFCNT_TRACKER -d SLUB_DEBUG_ON \ -d DEBUG_KMEMLEAK_AUTO_SCAN -e PANIC_ON_OOPS \ -e SOFTLOCKUP_DETECTOR -e BOOTPARAM_SOFTLOCKUP_PANIC \ -e HARDLOCKUP_DETECTOR -e BOOTPARAM_HUNG_TASK_PANIC \ -e DETECT_HUNG_TASK -e BOOTPARAM_HUNG_TASK_PANIC -e DEBUG_INFO \ -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e GDB_SCRIPTS \ -e DEBUG_INFO_DWARF4 -e DEBUG_INFO_COMPRESSED \ -e DEBUG_INFO_COMPRESSED_ZLIB -e DEBUG_INFO_BTF_MODULES \ -e MODULE_ALLOW_BTF_MISMATCH -d IA32_EMULATION -e DYNAMIC_DEBUG \ --set-val CONSOLE_LOGLEVEL_DEFAULT 8 -e FTRACE -e FUNCTION_TRACER \ -e DYNAMIC_FTRACE -e FTRACE_SYSCALLS -e HIST_TRIGGERS -e DEBUG_NET \ -m KUNIT -e KUNIT_DEBUGFS -d KUNIT_ALL_TESTS -m MPTCP_KUNIT_TEST \ -e BPF_JIT -e BPF_SYSCALL -e TUN -e CRYPTO_USER_API_HASH \ -e CRYPTO_SHA1 -e NET_SCH_TBF -e BRIDGE -d RETPOLINE -d PCCARD \ -d MACINTOSH_DRIVERS -d SOUND -d USB_SUPPORT -d NEW_LEDS -d SCSI \ -d SURFACE_PLATFORMS -d DRM -d FB -d ATA -d MISC_FILESYSTEMS # sorry, long list used by the MPTCP CI to accelerate builds, etc. $ make O=${PWD}/.virtme/build-debug-btf olddefconfig $ make O=${PWD}/.virtme/build-debug-btf -j$(nproc) -l$(nproc) $ make O=${PWD}/.virtme/build-debug-btf headers_install \ INSTALL_HDR_PATH=${PWD}/.virtme/headers $ make O=${PWD}/.virtme/build-debug-btf \ KHDR_INCLUDES=-I${PWD}/.virtme/headers/includes \ -C tools/testing/selftests/bpf - The errors I got should be reproducible using: $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \ -e INPUT_EXTRA_ENV=INPUT_RUN_TESTS_ONLY=bpftest_all \ --pull always mptcp/mptcp-upstream-virtme-docker:latest \ auto-btf-debug - These issues were originally spot by our MPTCP CI: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/18222911614/job... - No errors without kernel/configs/debug.config on the CI and on my side - This CI got different issues, and I had to declare more kfuncs there: https://github.com/multipath-tcp/mptcp_net-next/commit/4435d4da9f4f but this CI is currently on top of 'net', with Jiri's patches from https://lore.kernel.org/20251001122223.170830-1-jolsa@kernel.org - The builds have been done from a clean build directory each time. - Do you think the issue is on my side? Dependences? How the selftests are built? I didn't change the way the BPF selftests are built for a while. I had other issues with pahole 1.29, but fixed with 1.30. - Feel free to discard this patch for a better solution (if any). - I don't know which Fixes tag adding, but I doubt this patch is valid. --- tools/testing/selftests/bpf/progs/dynptr_success.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/progs/dynptr_success.c b/tools/testing/selftests/bpf/progs/dynptr_success.c index 127dea342e5a67dda33e0a39e84d135206d2f3f1..60daf5ce8eb283d8c8bf2d7853eda6313df4fa87 100644 --- a/tools/testing/selftests/bpf/progs/dynptr_success.c +++ b/tools/testing/selftests/bpf/progs/dynptr_success.c @@ -6,6 +6,7 @@ #include <stdbool.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_tracing.h> +#include "bpf_kfuncs.h" #include "bpf_misc.h" #include "errno.h"
--- base-commit: 63d2247e2e37d9c589a0a26aa4e684f736a45e29 change-id: 20251003-bpf-sft-fix-build-err-6-18-6a4c032f680a
Best regards,
On Fri, 2025-10-03 at 17:24 +0200, Matthieu Baerts (NGI0) wrote:
When trying to build the latest BPF selftests, with a debug kernel config, Pahole 1.30 and CLang 20.1.8 (and GCC 15.2), I got these errors:
progs/dynptr_success.c:579:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ progs/dynptr_success.c:579:9: note: did you mean 'bpf_dynptr_size'? .virtme/build-debug-btf//tools/include/vmlinux.h:120280:14: note: 'bpf_dynptr_size' declared here 120280 | extern __u32 bpf_dynptr_size(const struct bpf_dynptr *p) __weak __ksym; | ^ progs/dynptr_success.c:579:7: error: incompatible integer to pointer conversion assigning to '__u64 *' (aka 'unsigned long long *') from 'int' [-Wint-conversion] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ progs/dynptr_success.c:596:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ progs/dynptr_success.c:596:7: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't have these errors without the debug kernel config from kernel/configs/debug.config. With the debug kernel, bpf_dynptr_slice() is not declared in vmlinux.h. It is declared there without debug.config.
The fix is similar to what is done in dynptr_fail.c which is also using bpf_dynptr_slice(): bpf_kfuncs.h is now included.
Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org
I can reproduce similar issue when including kernel/configs/debug.config with my regular dev config, but for different functions: bpf_rcu_read_{un,}lock().
However, this is not a way to fix this. Kfuncs are not supposed to just disappear from DWARF.
Running pahole in verbose mode I see the following output:
$ pahole -V \ --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func,decl_tag_kfuncs \ --btf_features=attributes \ --lang_exclude=rust \ --btf_encode_detached=/dev/null vmlinux ... matched function 'bpf_rcu_read_lock' with 'bpf_rcu_read_lock.cold' ...
Alan, Ihor, does this sound familiar?
On 10/3/25 4:37 PM, Eduard Zingerman wrote:
On Fri, 2025-10-03 at 17:24 +0200, Matthieu Baerts (NGI0) wrote:
When trying to build the latest BPF selftests, with a debug kernel config, Pahole 1.30 and CLang 20.1.8 (and GCC 15.2), I got these errors:
progs/dynptr_success.c:579:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ progs/dynptr_success.c:579:9: note: did you mean 'bpf_dynptr_size'? .virtme/build-debug-btf//tools/include/vmlinux.h:120280:14: note: 'bpf_dynptr_size' declared here 120280 | extern __u32 bpf_dynptr_size(const struct bpf_dynptr *p) __weak __ksym; | ^ progs/dynptr_success.c:579:7: error: incompatible integer to pointer conversion assigning to '__u64 *' (aka 'unsigned long long *') from 'int' [-Wint-conversion] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ progs/dynptr_success.c:596:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ progs/dynptr_success.c:596:7: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't have these errors without the debug kernel config from kernel/configs/debug.config. With the debug kernel, bpf_dynptr_slice() is not declared in vmlinux.h. It is declared there without debug.config.
The fix is similar to what is done in dynptr_fail.c which is also using bpf_dynptr_slice(): bpf_kfuncs.h is now included.
Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org
I can reproduce similar issue when including kernel/configs/debug.config with my regular dev config, but for different functions: bpf_rcu_read_{un,}lock().
However, this is not a way to fix this. Kfuncs are not supposed to just disappear from DWARF.
Running pahole in verbose mode I see the following output:
$ pahole -V \ --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func,decl_tag_kfuncs \ --btf_features=attributes \ --lang_exclude=rust \ --btf_encode_detached=/dev/null vmlinux ... matched function 'bpf_rcu_read_lock' with 'bpf_rcu_read_lock.cold' ...
Alan, Ihor, does this sound familiar?
This is most likely the issue addressed in this patch: https://lore.kernel.org/dwarves/f7553b3f-5827-4f50-81a9-9bd0802734b9@linux.d...
There wasn't a new pahole release with it yet.
On 10/3/25 8:08 PM, Ihor Solodrai wrote:
On 10/3/25 4:37 PM, Eduard Zingerman wrote:
On Fri, 2025-10-03 at 17:24 +0200, Matthieu Baerts (NGI0) wrote: [...]
Alan, Ihor, does this sound familiar?
This is most likely the issue addressed in this patch: https://lore.kernel.org/dwarves/f7553b3f-5827-4f50-81a9-9bd0802734b9@linux.d...
There wasn't a new pahole release with it yet.
Not the best link, sorry. That patch wasn't picked up by lore, only discussion remains.
Here is the commit pushed to pahole/next: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=next&id...
Hi Ihor,
On 04/10/2025 05:19, Ihor Solodrai wrote:
On 10/3/25 8:08 PM, Ihor Solodrai wrote:
On 10/3/25 4:37 PM, Eduard Zingerman wrote:
On Fri, 2025-10-03 at 17:24 +0200, Matthieu Baerts (NGI0) wrote: [...]
Alan, Ihor, does this sound familiar?
This is most likely the issue addressed in this patch: https://lore.kernel.org/dwarves/f7553b3f-5827-4f50-81a9-9bd0802734b9@linux.d...
There wasn't a new pahole release with it yet.
Not the best link, sorry. That patch wasn't picked up by lore, only discussion remains.
Here is the commit pushed to pahole/next: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=next&id...
Thank you for the links!
OK so I guess to be (fully) able to use BTF in the future v6.18, we should use the future Pahole v1.31, and not include extra kfuncs. Is that correct?
If yes, we can drop this patch. (The MPTCP CI will use it internally not to have to depend on a dev version of Pahole.)
Also, should this dependency be more explicit somehow, to help people having errors when not using a recent enough Pahole version?
Cheers, Matt
Hi Eduard,
On 04/10/2025 01:37, Eduard Zingerman wrote:
On Fri, 2025-10-03 at 17:24 +0200, Matthieu Baerts (NGI0) wrote:
When trying to build the latest BPF selftests, with a debug kernel config, Pahole 1.30 and CLang 20.1.8 (and GCC 15.2), I got these errors:
progs/dynptr_success.c:579:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ progs/dynptr_success.c:579:9: note: did you mean 'bpf_dynptr_size'? .virtme/build-debug-btf//tools/include/vmlinux.h:120280:14: note: 'bpf_dynptr_size' declared here 120280 | extern __u32 bpf_dynptr_size(const struct bpf_dynptr *p) __weak __ksym; | ^ progs/dynptr_success.c:579:7: error: incompatible integer to pointer conversion assigning to '__u64 *' (aka 'unsigned long long *') from 'int' [-Wint-conversion] 579 | data = bpf_dynptr_slice(&ptr, 0, NULL, 1); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ progs/dynptr_success.c:596:9: error: call to undeclared function 'bpf_dynptr_slice'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ progs/dynptr_success.c:596:7: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion] 596 | data = bpf_dynptr_slice(&ptr, 0, NULL, 10); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't have these errors without the debug kernel config from kernel/configs/debug.config. With the debug kernel, bpf_dynptr_slice() is not declared in vmlinux.h. It is declared there without debug.config.
The fix is similar to what is done in dynptr_fail.c which is also using bpf_dynptr_slice(): bpf_kfuncs.h is now included.
Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org
I can reproduce similar issue when including kernel/configs/debug.config with my regular dev config, but for different functions: bpf_rcu_read_{un,}lock().
Thank you for having checked! I also had issues with these functions on my side, when testing on top of 'net'.
However, this is not a way to fix this. Kfuncs are not supposed to just disappear from DWARF.
Indeed. But strange it was fine before. Or fine without debug.config.
Cheers, Matt
linux-kselftest-mirror@lists.linaro.org