dwarves.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Ambardar <tony.ambardar@gmail.com>
To: andriin@fb.com
Cc: bpf@vger.kernel.org, dwarves@vger.kernel.org
Subject: Re: [PATCH dwarves 00/11] Switch BTF loading and encoding to libbpf APIs
Date: Sun, 4 Oct 2020 20:48:32 -0700	[thread overview]
Message-ID: <CAPGftE8-TxfyLKuLDowKKhOo5XtfD1YVO4Gv2+k1HqbL074G=A@mail.gmail.com> (raw)

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.

> 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,
                   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	other threads:[~2020-10-05  3:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05  3:48 Tony Ambardar [this message]
2020-10-05 19:30 ` [PATCH dwarves 00/11] Switch BTF loading and encoding to libbpf APIs Andrii Nakryiko
  -- 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAPGftE8-TxfyLKuLDowKKhOo5XtfD1YVO4Gv2+k1HqbL074G=A@mail.gmail.com' \
    --to=tony.ambardar@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).