Open kloczek opened 3 months ago
Hi - Thanks for reporting this issue. What distribution is this and does it have BTF enabled (check - /sys/kernel/btf/vmlinux)?
I'm using my own distribution but on build system is Fedora kernel.
[tkloczko@pers-jacek SPECS]$ ls -la /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 5923179 Apr 19 15:20 /sys/kernel/btf/vmlinux
Does it mean that what bpftool
is doing depends on system running kernel? 🤔
The -restrack switch (memory tracking) is built using eBPF which utilizes BTF. Having said that, your system seems to be BTF enabled so there is something else going on. We build and produce packages for RHEL so there must be something specific to your distribution.
Try adding --debug to the bpf build steps in the cmake file. Towards the bottom you should see:
bpftool gen object procdump.ebpf.o procdump_ebpf.o
Change it to:
bpftool --debug gen object procdump.ebpf.o procdump_ebpf.o
This may shed some more light on the problem.
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ bpftool --debug gen object procdump.ebpf.o procdump_ebpf.o; echo
libbpf: linker: adding object file 'procdump_ebpf.o'...
libbpf: failed to find BTF info for object 'procdump_ebpf.o'
Error: failed to link 'procdump_ebpf.o': Invalid argument (22)
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ ls -la procdump_ebpf.o
-rw-r--r-- 1 tkloczko tkloczko 27104 Apr 19 15:33 procdump_ebpf.o
I've been trying to test that using strace ..
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ strace -fe trace=file bpftool --debug gen object procdump.ebpf.o procdump_ebpf.o
execve("/usr/sbin/bpftool", ["bpftool", "--debug", "gen", "object", "procdump.ebpf.o", "procdump_ebpf.o"], 0x7fff868ff1f8 /* 30 vars */) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libelf.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libzstd.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "procdump.ebpf.o", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0644) = 3
libbpf: linker: adding object file 'procdump_ebpf.o'...
openat(AT_FDCWD, "procdump_ebpf.o", O_RDONLY|O_CLOEXEC) = 4
libbpf: failed to find BTF info for object 'procdump_ebpf.o'
Error: failed to link 'procdump_ebpf.o': Invalid argument (22)
+++ exited with 234 +++
So noting is trying to access to sysfs so kernel version and availability of the /sys/kernel/btf/vmlinux should not be relevant.
I've tested as well use bpdtools instead from package generated by me use package fro Fedora rawhide and result is the same
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ rpm -qf /usr/sbin/bpftool; echo
bpftool-6.9.0-0.rc4.20240416git96fca68c4fbf7.38.fc41.x86_64
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ bpftool --debug gen object procdump.ebpf.o procdump_ebpf.o
libbpf: linker: adding object file 'procdump_ebpf.o'...
libbpf: failed to find BTF info for object 'procdump_ebpf.o'
Error: failed to link 'procdump_ebpf.o': Invalid argument (22)
Here is full strace output
after delete procdump_ebpf.o':
So clang (18.1.4) generates that object file and than /usr/sbin/bpftool cannot link it. What about use gcc instead clang? In this case I'm playing with gcc from Fedora rawhide which IIRC should be able to build bpf code as well 🤔 (I don't know however how to do that)
Thanks. I think GCC can build BPF code nowadays but it's not something I have tried or is supported at the moment. Feel free to try it out if you want. There are a couple of other things to check:
As I wrote I'm using gcc from Fedora and looking on spec file I suppose as well that exactly those binaries should be able to compile bpf code and cannot only find details how to do that.
Yes kernel support BFP/BTF.
Will try later with libbpf-bootstrap
🤔
Not sure if this might help - https://gcc.gnu.org/wiki/BPFBackEnd
I've saw already that page and it cannot be used in context of Fedora binaries because fedora uses multiarch gcc/binutils setup and is not using crosscompilers for bpf. If I'll not find exact solution I'll try soon to open fedora ticket with question because I have very similar issue with dtrace https://github.com/oracle/dtrace-utils/issues/71
If Fedora would package the crosses for BPF that would be really nice and solve all these issues indeed.
In order to support memory leak tracking (using -restrack) switch, ProcDump relies on eBPF. One option is to remove the libbpf dependencies from the build (behind a new def, NO_RESTRACK or some such). This would avoid build failures for distros without proper eBPF support. Of course, this also means that the -restrack switch would not work on those builds.
In order to support memory leak tracking (using -restrack) switch, ProcDump relies on eBPF
That technique is known more than decade (since Solaris DTrace is known which Linux eBPF only mimics).
I'm not making any statements as to which technology came first or if one is better than the other :) Suffice to say, I was presenting an optional build strategy if you don't need memory leak tracking and hence can remove the dependency on eBPF.
cmake settings
cmake params and output:
And build fails with: