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=unavailable 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 24822C433ED for ; Thu, 13 May 2021 08:37:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D0EBD611CA for ; Thu, 13 May 2021 08:37:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232040AbhEMIik (ORCPT ); Thu, 13 May 2021 04:38:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231939AbhEMIig (ORCPT ); Thu, 13 May 2021 04:38:36 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4569C06174A for ; Thu, 13 May 2021 01:37:26 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id j10so37470188lfb.12 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=P7xm34x+VJoFifnJvm1LwlCWKuy1UuvdNb/cFhKkI76MuGHrxY5QSuE8A3xpW8BE4G tLjBJLoI9PfqqDFVAmopCO92yh77hyINbvs/Y3uslGP3rHDBE+MHdS8uuKX88VtiHZcG usIwL/17ahwYOoOqNf3F24AvzMmzg9T1flGt6gpgm/GXXQe8cKDwpYBPQGlE52Pb1QBG lmJOJsxtU7XicPC06qJnxo/Ljm8Lz/RglRTrF+DA7x2L85btO/neskTAQjvyibcyUVFw Wz4cga5tFQFQT0eNMpyCgBCaxigFZEckuFteTGb8ozsbC5u3qQL5srtIDAg0mQGXpkVz QYAw== X-Gm-Message-State: AOAM5328Ukkk8ymMN2haXmG3acDKV+Z4/pbaaruAQqwzA5WGF2MuZD7e lmm7HtaFVirWR7HZakbkByiE1WlrUAWoseJfPrrGJQ== 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: netdev@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