On Wed, Feb 6, 2019 at 1:18 PM Arnaldo Carvalho de Melo
<arnaldo.melo@xxxxxxxxx> wrote:
>
> Em Tue, Feb 05, 2019 at 11:24:44PM -0800, Andrii Nakryiko escreveu:
> > This is my initial take on how to start using libbpf from pahole with the intent
> > to reuse as much functionality from libbpf as possible. This is also necessary
> > to do BTF deduplication, because btf__dedup() is implemented only as part of
> > libbpf.
> >
> > Patch #2 adds submodule and corresponding cmake changes to build against libbpf.
> > Patch #3 removes pahole's btf.h copy and references one from libbpf to test
> > that libbpf is usable.
> >
> > If this approach will be deemed good, I'll continue refactoring of btf_encoder
> > and btf_loader to utilize libbpf more fully and also use btf__dedup.
>
> I think the approach is good, the end result is a working pahole:
>
> [acme@quaco pahole]$ pahole -F btf examples/dedup-btf/a
> struct foo {
> int a; /* 0 4 */
> char b; /* 4 1 */
>
> /* size: 8, cachelines: 1, members: 2 */
> /* padding: 3 */
> /* last cacheline: 8 bytes */
> };
> struct bar {
> int d; /* 0 4 */
> char e; /* 4 1 */
> unsigned char f; /* 5 1 */
>
> /* size: 8, cachelines: 1, members: 3 */
> /* padding: 2 */
> /* last cacheline: 8 bytes */
> };
> [acme@quaco pahole]$ file examples/dedup-btf/a
> examples/dedup-btf/a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=67ed8ec4f73c807666afd75c9584dbcfc3222915, with debug_info, not stripped
> [acme@quaco pahole]$ readelf -SW examples/dedup-btf/a | grep BTF
> [34] .BTF PROGBITS 0000000000000000 004454 0000eb 00 0 0 1
> [acme@quaco pahole]$
>
> So either resubmit this or let me know if I can keep these on and you
> can continue on top of it, ok?
Let me dig into all those warning and try to fix them. There is no
rush in landing this patchset immediately, I was mostly trying to get
consensus on whether using libbpf from submodule is ok for now (until
we have more readily available and more stable libbpf as a shared
lib).
>
> At some point we just switch to linking dynamicly with libbtf, when it
> becomes more generally available.
Yep, I agree.
>
> Thanks,
>
> - Arnaldo
