From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2B7AC433B4 for ; Thu, 13 May 2021 08:37:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BD923611CA for ; Thu, 13 May 2021 08:37:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232039AbhEMIig (ORCPT ); Thu, 13 May 2021 04:38:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232034AbhEMIif (ORCPT ); Thu, 13 May 2021 04:38:35 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65681C061574 for ; Thu, 13 May 2021 01:37:26 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id z13so37528461lft.1 for ; Thu, 13 May 2021 01:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PHaCWgEE6c4TCqnr20Y2Tb/elcO/UUWT8003QZ9uRCI=; b=LuOJKvNiAT8kHzQImtibnuxjXNT2Ftq34giDbSM3s+GbkMD+01nvAuPIr8cqgEqMZa PP0jbr9fUlYEvPQ5JzoZ+nu7Jq0hEni2K7zzLN7F2lZHj+GPsFZ07YHnNY9YWz6sg1tV UO3PX9KHVUBYDVJW39/Q13+Xp2/Q1IOqdLMgE= 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=PHaCWgEE6c4TCqnr20Y2Tb/elcO/UUWT8003QZ9uRCI=; b=jSJAHjwjsSSBhAiNJKmQ9o9r+VIyaYdh58IRXiqtmwmaeRbuz58etBS9sDiq5LFtIM eXpPPdAnnRom6+k6resRt1bFC5gAjeVdGyXaSAXDZJj2uw2bSqEhrAbFLhuNQOFAbU0N nDUaT/Cs3jTAix+9sM1GbDlVvJ2Eh0X4gToa4340YEcV8bbdKc3kMoJReUG+Co0iBZ9T Z6VeSb6UTO8EK6aDNmNXZJ8qMDVU2QzS0DlnD2c7j7UZw6EHNMy6vb/7njobkJSD3jkj DOnnsQkXcSIqHWLWPnoKFK9BX78hP6/kEePEvSW5T1YJKhfgKZcbFHeaoMmgUJYINofN 8c1Q== X-Gm-Message-State: AOAM530JoV67shLjN/vAO4HVyy4MIASS4LvIyzwh7mftEJrb0DdfOeA1 u5BcKsOPq5cTF/S/meo/gJFrpUBKO1DjvS6kxfDofQ== X-Google-Smtp-Source: ABdhPJzeRRycic2njXDn3pfCDB1CZHgy1g/M5uvhqHrDC3Ae39xKnZg0dj+/8raTcyBd/2FHcnwYd1v3KZ6CBxNySvE= X-Received: by 2002:a05:6512:3618:: with SMTP id f24mr28416584lfs.34.1620895044869; Thu, 13 May 2021 01:37:24 -0700 (PDT) MIME-Version: 1.0 References: <20210426223449.5njjmcjpu63chqbb@ast-mbp.dhcp.thefacebook.com> <20210427022231.pbgtrdbxpgdx2zrw@ast-mbp.dhcp.thefacebook.com> <20210428045545.egqvhyulr4ybbad6@ast-mbp.dhcp.thefacebook.com> <20210504044204.kpt6t5kaomj7oivq@ast-mbp> <20210511230505.z3rdnppplk3v3jce@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Lorenz Bauer Date: Thu, 13 May 2021 09:37:13 +0100 Message-ID: Subject: Re: bpf libraries and static variables. Was: [PATCH v2 bpf-next 2/6] libbpf: rename static variables during linking To: Andrii Nakryiko Cc: Alexei Starovoitov , Yonghong Song , Andrii Nakryiko , bpf , Networking , Alexei Starovoitov , Daniel Borkmann , Kernel Team , John Fastabend Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, 12 May 2021 at 19:50, Andrii Nakryiko wrote: > ... > So at least for BPF skeleton, the flow I was imagining would be > like this. Thank you for the worked out example, it's really helpful. > > 1. BPF library abc consists of abc1.bpf.c and abc2.bpf.c. It also has > user-space component in abc.c. > 2. BPF app uses abs library and has its own app1.bpf.c and app2.bpf.c > and app.c for user-space. > 3. BPF library author sets up its Makefile to do > a. clang -target bpf -g -O2 -c abc1.bpf.c -o abc1.bpf.o > b. clang -target bpf -g -O2 -c abc2.bpf.c -o abc2.bpf.o > c. bpftool gen lib libabc.bpf.o abc1.bpf.o abc2.bpf.o I think we can plug this into bpf2go [1] on our side in the best case, which would avoid duplicating the static linker. > d. bpftool gen subskeleton libabc.bpf.o > libabc.subskel.h > e. abc.c (user-space library) is of the form > > #include "libabc.subskel.h" > > static struct libabc_bpf *subskel; > > int libabc__init(struct bpf_object *obj) > { > subskel = libabc_bpf__open_subskel(obj); > > subskel->data->abc_my_var = 123; > } > > int libabc__attach() > { > libabc_bpf__attach(subskel); > } > > f. cc abc.c into libabc.a and then libabc.a and libabc.bpf.o are > distributed to end user > > 3. Now, from BPF application author side: > a. clang -target bpf -g -O2 -c app1.bpf.c -o app1.bpf.o > b. clang -target bpf -g -O2 -c app2.bpf.c -o app2.bpf.o > c. bpftool gen object app.bpf.o app1.bpf.o app2.bpf.o libabc.bpf.o I haven't worked out exactly how things would work, but on the Go side it might be possible to distribute libabc.bpf.o plus the Go "library" code as a package. So the Go toolchain would never create this merged object, but instead do bpftool gen object app.bpf.o app1.bpf.o app2.bpf.o and later link app.bpf.o and libabc.bpf.o at runtime. It would be simpler from our side if bpftool gen object could link both libraries and "programs", maybe we can discuss the details of this during office hours. 1: https://pkg.go.dev/github.com/cilium/ebpf/cmd/bpf2go -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com