Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp620558iob; Wed, 18 May 2022 09:17:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjg1v4m+XOdhnCbzBBOJvpsnVzjQmEZtk2fHhesQI+UIj0O/7+v9m5OHgHuAylxK9hRLRC X-Received: by 2002:a17:902:8644:b0:15a:3b4a:538a with SMTP id y4-20020a170902864400b0015a3b4a538amr350104plt.146.1652890661292; Wed, 18 May 2022 09:17:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652890661; cv=none; d=google.com; s=arc-20160816; b=pKlCnkoLWn7Ik9ig67zkmQpGjD7p4cS5/8W1VM6u3czVIDyn8VE8mf7AyNENd0LMt3 rjy+ByTcUO7+Lk6VfoCgHmtIYHXuuI131gznzK4DwZQfH4/Yi31NQvXZNZ9jjp4A2K+G kWpdH3MJqm+FEjPTi9wUz74ofBnuhjhmkHzgap0yDP+8WI/LGmaEKCFoLOv9vSOVch3H NKK2i8dYD4mbMNe4M4wM1hyjJfFYEuwy7v0WbDf5i8QBovnfu/C1PjE32cpZMSUFEFfe AVKzHT0DY/2oFP+GcaRkbXROd5sH3jl2aaFSyCQaj/pyezNPWmgoVW314pSCueD0L8D2 jiZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=f1Xfp4scL9RWN6fPO4jPmNqLQDAQGVrdSgoYlcBdULA=; b=UZA9ka2vJmrjLJJS/rGov3ysjqZXJGLE2bWcScITZK7noVHjhuBE7OSAqRL0ZdysU7 DRqQrDDA3vjdAYTRZYNBQhQEx4UNfx2IvGjyAv1UyyrBkKw5wmJ/FskdOJ4Ju6Ak3i2E 73H82RvwZxEyGREorp1WGHKK45OYVMLbCLrEWZXTq3c37lU2Z7FUDpZVop58rU6Mf6CB 46TZnmg07/gStAGZF4L4rg8+vop5mMT/xLsKf+okQ2KmMCxj52ogSw7d3eCInSYUNgpd 1vnUC1Y+BVedmhoA3mgxTfgw4pR/lbqjCXRmUlBnjiPqH7nto7h2t9HwU/11CLKkdAdX o2HQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jCo8ns3R; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h15-20020a056a00230f00b0051098abed4bsi3933415pfh.305.2022.05.18.09.17.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 09:17:41 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jCo8ns3R; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BDCA81E15D7; Wed, 18 May 2022 09:17:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240004AbiERQRe (ORCPT + 99 others); Wed, 18 May 2022 12:17:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239971AbiERQRc (ORCPT ); Wed, 18 May 2022 12:17:32 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2CE717707E for ; Wed, 18 May 2022 09:17:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 3737FCE21AE for ; Wed, 18 May 2022 16:17:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F140C385A5; Wed, 18 May 2022 16:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652890647; bh=dmIZ4Nql4iIBiLdds0xyVW1A/Xf8DpSW87Riaa/jSn0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jCo8ns3RJzooC9MrZspB4ZE24hbQ43csw2DVuEEk4WxhSfaJgll3XQ5Cib00iRTzE 8IwB5gI1ZOYGJFWB+VeSsEWSqeqA1T2trHsLXXlmMkjx5PvinxZgjpEnf3z7gLzZpf ubqm2S37FbwZtu2i1I7mcfM82SaCxT+nEiKn8ViA6qcfx3vg2QJUOIBFmLwq95gqGD 9OdtqmfQqzlhf2zB5FhiFTkOkGQmjQRQLLVNSyCaH5H0F7TAgUXxa3R+5wh5u+zJFS myB50Ehr1m94KuBTpPxhmWoy8AKKC5YGJr6N0c78Ucw9PShwNpI6qQjw/TOcvejYo2 1N2l67jZ1JmoA== Date: Wed, 18 May 2022 09:17:25 -0700 From: Josh Poimboeuf To: Peter Zijlstra Cc: Nathan Chancellor , Nick Desaulniers , llvm@lists.linux.dev, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Subject: Re: objtool "no non-local symbols" error with tip of tree LLVM Message-ID: <20220518161725.2bkzavre2bg4xu72@treble> References: <20220516214005.GQ76023@worktop.programming.kicks-ass.net> <20220518012429.4zqzarvwsraxivux@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2022 at 07:30:06AM +0200, Peter Zijlstra wrote: > On Tue, May 17, 2022 at 06:24:29PM -0700, Josh Poimboeuf wrote: > > On Tue, May 17, 2022 at 05:42:04PM +0200, Peter Zijlstra wrote: > > > + for (;;) { > > > + symtab_data = elf_getdata(s, symtab_data); > > > + if (t) > > > + shndx_data = elf_getdata(t, shndx_data); > > > > > > + if (!symtab_data) { > > > + if (!idx) { > > > + void *buf; > > > > I'm confused by whatever this is doing, how is !symtab_data possible, > > i.e. why would symtab not have data? > > Elf_Data *elf_getdata(Elf_Scn *scn, Elf_Data *data); > > is an iterator, if @data is null it will return the first element, which > you then feed into @data the next time to get the next element, once it > returns NULL, you've found the end. > > In our specific case, we iterate the data sections, if idx fits inside > the current section, we good, otherwise we lower idx by however many did > fit and try the next. Ok, I think I see. But why are there multiple data blocks to begin with? It's because of a previous call to elf_newdata() right? If so then I don't see how it would "fit" in an existing data block, since each block should already be full. Or... is the hole the one you just made, by moving the old symbol out? If so, the function seems weirdly generalized for the two distinct cases and the loop seems unnecessary. When adding a symbol at the end, just use elf_newdata(). When adding a symbol in the middle, the hole should be in the first data block. -- Josh