Dwarves Archive on lore.kernel.org
 help / color / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Tony Ambardar <tony.ambardar@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
Subject: Re: [PATCH dwarves 00/11] Switch BTF loading and encoding to libbpf APIs
Date: Mon, 5 Oct 2020 12:30:08 -0700
Message-ID: <CAEf4BzZ6VZR_3pGKqh0UXmJyS05_7LdUeoH39y+Xwc5T6F0=+A@mail.gmail.com> (raw)
In-Reply-To: <CAPGftE8-TxfyLKuLDowKKhOo5XtfD1YVO4Gv2+k1HqbL074G=A@mail.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
> >

  reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05  3:48 Tony Ambardar
2020-10-05 19:30 ` Andrii Nakryiko [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-09-30  4:27 Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEf4BzZ6VZR_3pGKqh0UXmJyS05_7LdUeoH39y+Xwc5T6F0=+A@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=tony.ambardar@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Dwarves Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dwarves/0 dwarves/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dwarves dwarves/ https://lore.kernel.org/dwarves \
	public-inbox-index dwarves

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git