Re: [PATCH dwarves 00/11] Switch BTF loading and encoding to libbpf APIs

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Sun, Oct 4, 2020 at 8:48 PM Tony Ambardar <tony.ambardar@gmail.com> 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
> >