Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp351684ybl; Mon, 2 Dec 2019 11:44:01 -0800 (PST) X-Google-Smtp-Source: APXvYqyiLthaK0dqniFtzpEU1OA/obUAml9E5iV6u5UZDU7nYIkGPU1pRa45BgGC+GXGH73ERys9 X-Received: by 2002:a17:906:ff01:: with SMTP id zn1mr958610ejb.323.1575315841007; Mon, 02 Dec 2019 11:44:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575315841; cv=none; d=google.com; s=arc-20160816; b=it0j3CLV+jgW1YHmu8/PVno+Y6ti+/IRWAHntXj0mg1bB/tipHLh4tA5v37bT1atjA hBvo1vbi2kiZHR4SzO0oI2J5u354Akz3MonAXrSjxfGCc6Yfhb5ixduMg0CpWQ1opWyQ PFFzXUHrsDNM2m9Ya9jfnRTix4zx5jzsDN+1YrE8j32/J3bj4NeRrCShlOuDt3aOWUNx FKiHfg3/r5f8H44pPGJSfPWFkQkwRwz9fghEeY6AXM7D4P2wF0esLFUN3+/uV6i9QbMg PMNtAmGDFhFmCTxSuBy3ryBy/9TwUfkZgUUIORCnDuOSZ3KoXl8DW0hMtw5wsLh4nbs4 aXcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hnXSdtM2jXSIPFsEbX5RTRrRiyHO+CE1VUT7gOr/2M4=; b=DQKdhU3k/dqKpNh/LxwqWcCMIhYnMmEcNe9BaG8jrfS1nb+Qv4TarkzYeHL9bWtxKO Ym/nA2Lw/cCzXb7+6hCRJgEUp9uaSusrUa1LwHmfYU16me9ZoV3gS2001UC8YABrehmF 3C2XIhQJYxeZXLJcpg/lyNu/kwrgIkaAnK60xagoKl0m/A3+lGGYBK5iumUgtFFPotrl Z63jKhg3iNdl8iwPORvc03h7E08AVYY20l8pWjPDAcaUCDUCUQD5EHA1tgkL9ZZBXzu8 SzPf/5Lba4OPe2UjZF1NSRt0HqDuB8FCV+mUgGCZ8/3Cp/ZMNPcEkMikxF6zbQylUPDh hGcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fCK6Gg8h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y21si391375ejb.75.2019.12.02.11.43.37; Mon, 02 Dec 2019 11:44:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fCK6Gg8h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728075AbfLBTlT (ORCPT + 99 others); Mon, 2 Dec 2019 14:41:19 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:37912 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727927AbfLBTlS (ORCPT ); Mon, 2 Dec 2019 14:41:18 -0500 Received: by mail-qt1-f195.google.com with SMTP id 14so998548qtf.5; Mon, 02 Dec 2019 11:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hnXSdtM2jXSIPFsEbX5RTRrRiyHO+CE1VUT7gOr/2M4=; b=fCK6Gg8hYc4SNe745wEdMOVP+HtvK5sIkeU+cJ9KOrU6HoobGT7wOKZIPSnqa/5RgO y6IA78Ybfqj2vuAeKNjfIR/GWPdPntaYhKI7S42diypnq3yh1qC0tOwuEtFlbOhDj4JL /RHHfmX4P9dIH72B02JeorGddEv8Qa+XJi92XXQMJaFDvDBpg1Qm2Ke/iHRIsAUIzlI8 toRVUbdW3tqkpsA85WUDvfkk0zimuhDVLnOui1whGGXAL/5NzOiIVH7P8G7n5YBpAR8s i+VjMftbIzfS5NECgnKmhglTxN/u7E1ub0T47mriepqjskO3pEtP0rzIPPHknFyu8hEv 9zzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hnXSdtM2jXSIPFsEbX5RTRrRiyHO+CE1VUT7gOr/2M4=; b=fAP3MVtVlYubAm9NM2P7wDv5VylStDxVApxwcTyL16KVDI6fnEUKPnPoPQTx83FwJw wIzNQHPZORzHtIL02As/7hV5Y+3pxEdTwJl69Btd5zb+M5XT1GpkuXQEJHi1NDQqHRDE Ez+OncWNFxxhehktdBe/aP0LLWxFhurlTzUe5Aer9GTR6ezRpertn5Y/8c4Yw/P+lfvL l9N9jQM4RGCatVXAX2mL9zL3sFX9X6MrYaxJ8y/+9NnfK5HI3cE9G7YEoW3y8T0xzksw BF1OzMYpnHe13Yrq9f4hkOnOnn00wz+PU770osGrg2mRZkVWI2r7VFjzvv1ZqifISVLG Hw0A== X-Gm-Message-State: APjAAAXYPtubudkl/BsFd9o4SZTbbgZaqmeUgGCfXedIaFj5atlYDGeF L7gku8bmSCH0o73bBxooADO4x3ZngmKGyqHpY7g= X-Received: by 2002:ac8:5457:: with SMTP id d23mr1081151qtq.93.1575315676789; Mon, 02 Dec 2019 11:41:16 -0800 (PST) MIME-Version: 1.0 References: <20191202131847.30837-1-jolsa@kernel.org> In-Reply-To: <20191202131847.30837-1-jolsa@kernel.org> From: Andrii Nakryiko Date: Mon, 2 Dec 2019 11:41:05 -0800 Message-ID: Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , lkml , Networking , bpf , Ingo Molnar , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Michael Petlan , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Jesper Dangaard Brouer , Daniel Borkmann , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , Quentin Monnet Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 2, 2019 at 5:19 AM Jiri Olsa 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(-) >