On Mon, Nov 29, 2021 at 6:50 PM Pony Sew <poony20115@xxxxxxxxx> wrote: > > No worries, thanks for the update! You are probably busy with Libbpf project, so take your time. I think I'll try "const volatile" method. > > Best regards, > Poony. > Please don't top post when sending email to the mailing list. This issue was fixed (see [0]) and synced to Github. I forgot to CC you on the patch itself, sorry. If you update to latest libbpf version, the issue should be gone. [0] https://github.com/libbpf/libbpf/commit/5c31bcf220f66e70f39fd141f5b0c55c6ab65e8e > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> 於 2021年11月19日 週五 06:39 寫道： >> >> 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.
