On Mon, Nov 15, 2021 at 1:48 AM Pony Sew <poony20115@xxxxxxxxx> wrote: > > Hello, > This (https://github.com/sartura/ebpf-core-sample) is the code I'm using. > But I add " #define BPF_NO_GLOBAL_DATA 1 " on 'hello.bpf.c' so that > Debian 10 is able to execute it. > Compiled on default Debian11 amd64 environment with clang package > installed from mirror source. > Both 'hello' and 'maps' used to work on Debian10 about a month ago. > But 'hello' now can't. I'd like to improve this result. > ----------------------------------------------------------------------------------------- > This is how I compiled them in steps: > > # bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h > # clang -g -O2 -target bpf -D__TARGET_ARCH_x86_64 -I . -c hello.bpf.c -o > # hello.bpf.o > # bpftool gen skeleton hello.bpf.o > hello.skel.h > # clang -g -O2 -Wall -I . -c hello.c -o hello.o > # git clone https://github.com/libbpf/libbpf > # cd libbpf/src > # make BUILD_STATIC_ONLY=1 OBJDIR=../build/libbpf DESTDIR=../build > INCLUDEDIR= LIBDIR= UAPIDIR= install > # cd ../../ > # clang -Wall -O2 -g hello.o libbpf/build/libbpf.a -lelf -lz -o hello > > There was only one warning message: "libbpf: elf: skipping > unrecognized data section(4) .rodata.str1.1", which appeared during > the generation of 'hello.skel.h'. There are no other warning and error > messages during this whole 'hello' and 'maps' compilation. > ------------------------------------------------------------------------------------------------------------------- > Result of executing 'hello' on default amd64 Debian10 environment: > > libbpf: kernel doesn't support global data Sorry for the late reply, I didn't ignore or forget, I was trying to come up with the best solution. In short, I suspect it's because of the recent libbpf feature to support multiple .rodata.* sections. In your case, kernel is old and doesn't support those special maps, but Clang actually sometimes emits unused .rodata.strN.M sections. No code is referencing them, yet compiler stubbornly emits them. After recent changes libbpf will try to create a map for such sections which is causing "kernel doesn't support global data" error. I think I'm going to teach libbpf to recognize such maps that are not referenced from BPF program code and not create them, if kernel doesn't support global data. Will need to see how to do it in the least intrusive way, but I'm going to solve this before official 0.6 release. Thanks for reporting. Stay tuned for the solution. > libbpf: failed to load object 'hello_bpf' > libbpf: failed to load BPF skeleton 'hello_bpf': -95 > failed to load BPF object -95 > ------------------------------------------------------------------------------------------------------------------- > From what I can remember, That warning message used to appear even > when I'm executing 'hello' on Debian10. But the BPF program work just > fine then. Maybe there is something else I can do? > > Sincerely, > Poony.
