On Sun, Oct 4, 2020 at 8:48 PM Tony Ambardar <tony.ambardar@xxxxxxxxx> wrote: > > On Tue, Sep 29, 2020 at 09:27:31PM -0700, Andrii Nakryiko wrote: > > This patch set switches pahole to use libbpf-provided BTF loading and encoding > > APIs. This reduces pahole's own BTF encoding code, speeds up the process, > > reduces amount of RAM needed for DWARF-to-BTF conversion. Also, pahole finally > > gets support to generating BTF for cross-compiled ELF binaries with different > > endianness (patch #11). > > > Hello Andrii, > > After a small hiccup (see below) I managed to build a modified 'pahole' and test > cross-compiling from x86_64 to mips 64/32-bit and big/little-endian > targets. Using > "bpftool btf dump file /sys/kernel/btf/vmlinux format c" succeeded on > all targets, > whereas prior to your changes running on big-endian targets would > raise an error. > (Note that the 'bpftool' used a 'libbpf' without any of your changes.) > > Thanks so much for tackling these BTF endianness problems; it's been a great > help for working with embedded systems. > Awesome, thanks for confirming! With this and libbpf patches to do integer/pointer load/store auto-resizing, 32-bit arches should be in a better shape w.r.t. BPF usage. > > Additionally, patch #6 fixes previously missed problem with invalid array > > index type generation. > > > > Patches #7-10 are speeding up DWARF-to-BTF convertion/dedup pretty > > significantly, saving overall about 9 seconds out of current 27 or so. > > > > Patch #8 revamps how per-CPU BTF variables are emitted, eliminating repeated > > and expensive looping over ELF symbols table. > > > > Patch #10 admittedly has some hacky parts to satisfy CTF use case, but its > > speed ups are greatest. So I'll understand if it gets dropped, but it would be > > a pity. > > > Possibly a case of operator error, but I had to skip this patch to > cleanly build 'pahole', > and didn't have much chance to look into the compile error: > > [ 1%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o > In file included from /home/kodidev/pahole/strings.h:9, > from /usr/include/string.h:432, There seems to be some issue with including pahole's strings.h header from /usr/include/string.h, which doesn't seem right, but I can't really repro this locally. I wonder if Arnaldo will see this in his setup as well. This might be your local setup problem. > from /home/kodidev/pahole/lib/bpf/src/libbpf_common.h:12, > from /home/kodidev/pahole/lib/bpf/src/libbpf.h:20, > from /home/kodidev/pahole/lib/bpf/src/ringbuf.c:20: > /home/kodidev/pahole/lib/bpf/src/btf.h:33:11: error: expected ‘;’ > before ‘void’ > 33 | LIBBPF_API void btf__free(struct btf *btf); > | ^~~~~ > | ; > > Kind regards, > Tony > > > More details could be found in respective patches. > > > > Andrii Nakryiko (11): > > libbpf: update to latest libbpf version > > btf_encoder: detect BTF encoding errors and exit > > dwarves: expose and maintain active debug info loader operations > > btf_loader: use libbpf to load BTF > > btf_encoder: use libbpf APIs to encode BTF type info > > btf_encoder: fix emitting __ARRAY_SIZE_TYPE__ as index range type > > btf_encoder: discard CUs after BTF encoding > > btf_encoder: revamp how per-CPU variables are encoded > > dwarf_loader: increase the size of lookup hash map > > strings: use BTF's string APIs for strings management > > btf_encoder: support cross-compiled ELF binaries with different > > endianness > >
