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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 21E71C43331 for ; Tue, 12 Nov 2019 21:25:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 002AE20659 for ; Tue, 12 Nov 2019 21:25:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbfKLVZ1 (ORCPT ); Tue, 12 Nov 2019 16:25:27 -0500 Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:58506 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726906AbfKLVZ1 (ORCPT ); Tue, 12 Nov 2019 16:25:27 -0500 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 8B6FA400098; Tue, 12 Nov 2019 21:25:25 +0000 (UTC) Received: from [10.17.20.203] (10.17.20.203) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Nov 2019 21:25:10 +0000 Subject: Re: static and dynamic linking. Was: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF To: Alexei Starovoitov , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= CC: John Fastabend , Daniel Borkmann , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , Marek Majkowski , Lorenz Bauer , Alan Maguire , Jesper Dangaard Brouer , David Miller , , References: <5da4ab712043c_25f42addb7c085b83b@john-XPS-13-9370.notmuch> <87eezfi2og.fsf@toke.dk> <87r23egdua.fsf@toke.dk> <70142501-e2dd-1aed-992e-55acd5c30cfd@solarflare.com> <874l07fu61.fsf@toke.dk> <87eez4odqp.fsf@toke.dk> <20191112025112.bhzmrrh2pr76ssnh@ast-mbp.dhcp.thefacebook.com> <87h839oymg.fsf@toke.dk> <20191112195223.cp5kcmkko54dsfbg@ast-mbp.dhcp.thefacebook.com> From: Edward Cree Message-ID: <8c251f3d-67bd-9bc2-8037-a15d93b48674@solarflare.com> Date: Tue, 12 Nov 2019 21:25:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20191112195223.cp5kcmkko54dsfbg@ast-mbp.dhcp.thefacebook.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.17.20.203] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-25038.003 X-TM-AS-Result: No-3.376300-8.000000-10 X-TMASE-MatchedRID: VfovoVrt/obmLzc6AOD8DfHkpkyUphL92oQN+Q/21gTXLRpcXl5f6Hi1 9VmdeeTeTEki2VoSh3OahIW1kCatWsuRBwUhxclNBjNCJF/iXbG6s6UL48vRAMsh83hywc54NyR 9yudqy2SRTH9S8o7AzQlzvpzzhhC0jeydHFnA4nkFKwjjJHbgBFWBVWOe7+fX0HC66mQRqD/V9x 7gL2l/MkmWjzn4zelHjVwOiEQlwVPUP+i/4eUoEnw6481wsCtCFTFJRL+t8UtGMe+tDjQ3Fq5Pq qbCfIUPvgeYjOys8+fl5ftrM+CQ9q+/EguYor8cgxsfzkNRlfLdB/CxWTRRuwihQpoXbuXFlnu+ TS9e3C7i5vg6AE5Ku30/m/3qz/XjDndCTNqDNTXwPBjnakTbmXW36pe/wPJ5VGl3mPvY+jXOnZY ws3d4dGCiAEKXfTTlooBB8uyeEuspZK3gOa9uGmJwouYrZN4qaw+fkLqdalOeqD9WtJkSIw== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--3.376300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25038.003 X-MDID: 1573593926-vjhoyKufPu4S Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 12/11/2019 19:52, Alexei Starovoitov wrote: > We haven't yet defined what 'extern' keyword in the program means. > There are a preliminary patches for llvm to support extern variables. Extern > functions are not done yet. We have to walk before we run. With dynamic linking > I'm proposing an api for the kernel that I think will work regardless of how > libbpf and llvm decide to define the meaning of 'extern'. Fwiw the 'natural' C way of doing it would be that for any extern symbol in  the C file, the ELF file gets a symbol entry with st_shndx=SHN_UNDEF, and  code in .text that uses that symbol gets relocation entries.  That's (AIUI)  how it works on 'normal' architectures, and that's what my ebld linker  understands; when it sees a definition in another file for that symbol  (matched just by the symbol name) it applies all the relocations of the  symbol to the appropriate progbits. I don't really see what else you could define 'extern' to mean. > Partial verification should be available regardless of > whether kernel performs dynamic linking or libbpf staticly links multiple .o > together. It's not clear to me how partial verification would work for statically  linked programs — could you elaborate on this? -Ed