netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Michael Petlan" <mpetlan@redhat.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Andrii Nakryiko" <andriin@fb.com>,
	"Quentin Monnet" <quentin.monnet@netronome.com>
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically
Date: Mon, 2 Dec 2019 11:41:05 -0800	[thread overview]
Message-ID: <CAEf4BzY_D9JHjuU6K=ciS70NSy2UvSm_uf1NfN_tmFz1445Jiw@mail.gmail.com> (raw)
In-Reply-To: <20191202131847.30837-1-jolsa@kernel.org>

On Mon, Dec 2, 2019 at 5:19 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> hi,
> adding support to link bpftool with libbpf dynamically,
> and config change for perf.
>
> It's now possible to use:
>   $ make -C tools/bpf/bpftool/ LIBBPF_DYNAMIC=1
>
> which will detect libbpf devel package and if found, link it with bpftool.
>
> It's possible to use arbitrary installed libbpf:
>   $ make -C tools/bpf/bpftool/ LIBBPF_DYNAMIC=1 LIBBPF_DIR=/tmp/libbpf/
>
> I based this change on top of Arnaldo's perf/core, because
> it contains libbpf feature detection code as dependency.
>
> Also available in:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   libbpf/dyn
>
> v4 changes:
>   - based on Toke's v3 post, there's no need for additional API exports:
>
>     Since bpftool uses bits of libbpf that are not exported as public API in
>     the .so version, we also pass in libbpf.a to the linker, which allows it to
>     pick up the private functions from the static library without having to
>     expose them as ABI.

Whoever understands how this is supposed to work, can you please
explain? From reading this, I think what we **want** is:

- all LIBBPF_API-exposed APIs should be dynamically linked against libbpf.so;
- everything else used from libbpf (e.g., netlink APIs), should come
from libbpf.a.

Am I getting the idea right?

If yes, are we sure it actually works like that in practice? I've
compiled with LIBBPF_DYNAMIC=1, and what I see is that libelf, libc,
zlib, etc functions do have relocations against them in ".rela.plt"
section. None of libbpf exposed APIs, though, have any of such
relocations. Which to me suggests that they are just statically linked
against libbpf.a and libbpf.so is just recorded in ELF as a dynamic
library dependency because of this extra -lbpf flag. Which kind of
defeats the purpose of this whole endeavor, no?

I'm no linker expert, though, so I apologize if I got it completely
wrong, would really appreciate someone to detail this a bit more.
Thanks!

>
>   - changing some Makefile variable names
>   - documenting LIBBPF_DYNAMIC and LIBBPF_DIR in the Makefile comment
>   - extending test_bpftool_build.sh with libbpf dynamic link
>
> thanks,
> jirka
>
>
> ---
> Jiri Olsa (6):
>       perf tools: Allow to specify libbpf install directory
>       bpftool: Allow to link libbpf dynamically
>       bpftool: Rename BPF_DIR Makefile variable to LIBBPF_SRC_DIR
>       bpftool: Rename LIBBPF_OUTPUT Makefile variable to LIBBPF_BUILD_OUTPUT
>       bpftool: Rename LIBBPF_PATH Makefile variable to LIBBPF_BUILD_PATH
>       selftests, bpftool: Add build test for libbpf dynamic linking
>
>  tools/bpf/bpftool/Makefile                        | 54 ++++++++++++++++++++++++++++++++++++++++++++++--------
>  tools/perf/Makefile.config                        | 27 ++++++++++++++++++++-------
>  tools/testing/selftests/bpf/test_bpftool_build.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 119 insertions(+), 15 deletions(-)
>

  parent reply	other threads:[~2019-12-02 19:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 13:18 [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Jiri Olsa
2019-12-02 13:18 ` [PATCH 1/6] perf tools: Allow to specify libbpf install directory Jiri Olsa
2019-12-02 13:18 ` [PATCH 2/6] bpftool: Allow to link libbpf dynamically Jiri Olsa
2019-12-02 13:18 ` [PATCH 3/6] bpftool: Rename BPF_DIR Makefile variable to LIBBPF_SRC_DIR Jiri Olsa
2019-12-02 13:18 ` [PATCH 4/6] bpftool: Rename LIBBPF_OUTPUT Makefile variable to LIBBPF_BUILD_OUTPUT Jiri Olsa
2019-12-02 13:18 ` [PATCH 5/6] bpftool: Rename LIBBPF_PATH Makefile variable to LIBBPF_BUILD_PATH Jiri Olsa
2019-12-02 13:18 ` [PATCH 6/6] selftests, bpftool: Add build test for libbpf dynamic linking Jiri Olsa
2019-12-02 15:38   ` Quentin Monnet
2019-12-02 19:41 ` Andrii Nakryiko [this message]
2019-12-02 21:15   ` [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Toke Høiland-Jørgensen
2019-12-04  5:52     ` Alexei Starovoitov
2019-12-04  9:01       ` Jiri Olsa
2019-12-04 10:57       ` Toke Høiland-Jørgensen
2019-12-04 17:39         ` Alexei Starovoitov
2019-12-04 18:27           ` Daniel Borkmann
2019-12-04 20:22             ` Toke Høiland-Jørgensen
2019-12-04 21:16       ` Andrii Nakryiko
2019-12-04 21:54         ` Jakub Kicinski
2019-12-04 23:39           ` Alexei Starovoitov
2019-12-05  0:23             ` Jakub Kicinski
2019-12-05  0:29               ` David Miller
2019-12-05  1:25                 ` Alexei Starovoitov
2019-12-05  1:09               ` Alexei Starovoitov
2019-12-05  2:10                 ` Jakub Kicinski
2019-12-05  3:17                   ` Alexei Starovoitov
2019-12-05  4:26                     ` Jakub Kicinski
2019-12-05  6:44                       ` Alexei Starovoitov
2019-12-05  8:35             ` Jesper Dangaard Brouer
2019-12-05 12:09               ` Michal Rostecki

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='CAEf4BzY_D9JHjuU6K=ciS70NSy2UvSm_uf1NfN_tmFz1445Jiw@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=quentin.monnet@netronome.com \
    --cc=songliubraving@fb.com \
    --cc=toke@redhat.com \
    --cc=yhs@fb.com \
    /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).