Message ID | 20221114114344.18650-9-jirislaby@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2097480wru; Mon, 14 Nov 2022 03:47:14 -0800 (PST) X-Google-Smtp-Source: AA0mqf4MQDxIme5fLOO3bXFr3IKZPDI8+WXow/cpJcwHBt1kN8Y3H7wPUBzEFUrT1TPp+9+uiqpH X-Received: by 2002:a17:906:8556:b0:7ad:e518:13fd with SMTP id h22-20020a170906855600b007ade51813fdmr9832389ejy.323.1668426434545; Mon, 14 Nov 2022 03:47:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668426434; cv=none; d=google.com; s=arc-20160816; b=fngdi0j8Bkr5aBS0jlF68Cb+9cNyREkHNo8c4qQTpdH7PPZe3RVBHvtLNoXQXNlxbk fr1H5RNIHCfqVS0TAj7eJlNosXe5fJkTEnqmZ3Sr3edUCi4FnlriMQPVNT6hiOPJ+QWo Tg5dA0he+NVoo55w+Gh1XK3vkFIN5rj+X73EhsMfKbprWBk+jU2cDeZeLv1Z62S/Mqg6 EBFxJHtbuuxsSg4XeyjBjlOOc4rdfBThHgZ7/77VOIWA6ukxSbTAskI4ABu7IBCQhD4l OuUHn0br65x1tSkz3R7HQgX6NMsiHV/1gTqsHnnmJIXg5ZjD/JYjBmyrMg7IT44Sj6h3 /fkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=1CxlOcKzQ0vxdHUvxkgIa7B/Q9F+YJOBlGe2kn/lJ7g=; b=CDlOEStMfF1nEh+IEiitUYv3jVXxifJpTzD9h91JY69h55EuuRKnrVVux0jBbPO3gV pUqfV9mJrs2GmghIKB0155rv/TB1toHV+tucXIWiLhEILW5cd8E1iwSdljF1aVb1sx6c S/MgsbMaRqWcazwil4Ka2/sbLkuRqSCw0/uPHxNJSxAbi0Kp4pn593GUhHmy7IOqg9T4 LqBKwYdVTnMKtsobk+F9yClICrJ2akgWWMkxU+n5rdh98A0MA8G9Re6y+rjXl5dnSVAs 0/79iOwqKNLQIy9yY+E2/nKpJn8jzhbJTK1Ktu6Mu7sutoYlHorfLQlOoye5797PfuEE nfww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SihAYQgv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw6-20020a170906478600b007ada03062e9si9657709ejc.415.2022.11.14.03.46.51; Mon, 14 Nov 2022 03:47:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SihAYQgv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236520AbiKNLor (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Mon, 14 Nov 2022 06:44:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236609AbiKNLoX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 14 Nov 2022 06:44:23 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9408521805 for <linux-kernel@vger.kernel.org>; Mon, 14 Nov 2022 03:44:13 -0800 (PST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 3008361046 for <linux-kernel@vger.kernel.org>; Mon, 14 Nov 2022 11:44:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F554C433D6; Mon, 14 Nov 2022 11:44:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668426252; bh=S8zV5neWzdzrlGujgojwhqUti56G0WJU8dL7d971SiM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SihAYQgv52omW1PHZ7cmu4VDkPbbFO0lMbLv/yfk8erdeDjAQyjrBr3yGTTwox7IF Ez9f5u2OzS1qjPZx2X4xADHcbceCYo8rGgROF9gCcRzQEhv9EypZxQ6bU4rBaFwd75 HlCpTRlUj3Mi4Y6o/m1lQWqlhCJiPGjKyyDG0opL7PI3mksDmV+Lg1p6F/PELxh62b n70ERWMmGlZ8Gif7c+RgN3L4z/OXk41zToHMprzJX4ncClKV1QV3+ZLkKp0Apa4x3+ 9v1G3ZTOrimok0l0MzFd/dh2NaoW7PY5Md7wnJQYAq8Y1azQg0B3p2vfVrJ+Wd48RS EEDp7zxbepynw== From: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> To: linux-kernel@vger.kernel.org Cc: Andi Kleen <andi@firstfloor.org>, Peter Zijlstra <peterz@infradead.org>, Josh Poimboeuf <jpoimboe@kernel.org>, Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>, Martin Liska <mliska@suse.cz>, Jiri Slaby <jslaby@suse.cz> Subject: [PATCH 08/46] static_call, lto: Mark static keys as __visible Date: Mon, 14 Nov 2022 12:43:06 +0100 Message-Id: <20221114114344.18650-9-jirislaby@kernel.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221114114344.18650-1-jirislaby@kernel.org> References: <20221114114344.18650-1-jirislaby@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749471916772413037?= X-GMAIL-MSGID: =?utf-8?q?1749471916772413037?= |
Series |
gcc-LTO support for the kernel
|
|
Commit Message
Jiri Slaby
Nov. 14, 2022, 11:43 a.m. UTC
From: Andi Kleen <andi@firstfloor.org> Symbols referenced from assembler (either directly or e.f. from DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because they could end up in a different object file than the assembler. This can lead to linker errors without this patch. So mark static call functions as __visible, namely static keys here. Cc: Peter Zijlstra <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Jason Baron <jbaron@akamai.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Andi Kleen <andi@firstfloor.org> Signed-off-by: Martin Liska <mliska@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz> --- include/linux/static_call.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Comments
On Mon, Nov 14, 2022 at 12:43:06PM +0100, Jiri Slaby (SUSE) wrote: > From: Andi Kleen <andi@firstfloor.org> > > Symbols referenced from assembler (either directly or e.f. from > DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because > they could end up in a different object file than the assembler. This > can lead to linker errors without this patch. > > So mark static call functions as __visible, namely static keys here. Why doesn't llvm-lto need this? Also, why am I getting a random selection of the patchset?
On Mon, Nov 14, 2022 at 04:51:07PM +0100, Peter Zijlstra wrote: > On Mon, Nov 14, 2022 at 12:43:06PM +0100, Jiri Slaby (SUSE) wrote: > > From: Andi Kleen <andi@firstfloor.org> > > > > Symbols referenced from assembler (either directly or e.f. from > > DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because > > they could end up in a different object file than the assembler. This > > can lead to linker errors without this patch. > > > > So mark static call functions as __visible, namely static keys here. > > Why doesn't llvm-lto need this? > > Also, why am I getting a random selection of the patchset? Same, please Cc me on the whole set next time.
On Mon, Nov 14, 2022 at 12:43:06PM +0100, Jiri Slaby (SUSE) wrote: > From: Andi Kleen <andi@firstfloor.org> > > Symbols referenced from assembler (either directly or e.f. from > DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because > they could end up in a different object file than the assembler. This > can lead to linker errors without this patch. > > So mark static call functions as __visible, namely static keys here. > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Josh Poimboeuf <jpoimboe@kernel.org> > Cc: Jason Baron <jbaron@akamai.com> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Andi Kleen <andi@firstfloor.org> > Signed-off-by: Martin Liska <mliska@suse.cz> > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > --- > include/linux/static_call.h | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/include/linux/static_call.h b/include/linux/static_call.h > index df53bed9d71f..e629ab0c4ca3 100644 > --- a/include/linux/static_call.h > +++ b/include/linux/static_call.h > @@ -182,7 +182,7 @@ extern long __static_call_return0(void); > > #define DEFINE_STATIC_CALL(name, _func) \ > DECLARE_STATIC_CALL(name, _func); \ > - struct static_call_key STATIC_CALL_KEY(name) = { \ > + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ Why not __visible_on_lto?
On Mon, Nov 14, 2022 at 04:51:07PM +0100, Peter Zijlstra wrote: > On Mon, Nov 14, 2022 at 12:43:06PM +0100, Jiri Slaby (SUSE) wrote: > > From: Andi Kleen <andi@firstfloor.org> > > > > Symbols referenced from assembler (either directly or e.f. from > > DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because > > they could end up in a different object file than the assembler. This > > can lead to linker errors without this patch. > > > > So mark static call functions as __visible, namely static keys here. > > Why doesn't llvm-lto need this? It has an integrated assembler that can feed this information to the LTO symbol table, while gas cannot do that. There was some discussion to extend the gcc top level asm syntax to express external symbols, but so far it doesn't exist. > > Also, why am I getting a random selection of the patchset? Me too. -Andi
On Mon, Nov 14, 2022 at 12:34:33PM -0800, Andi Kleen wrote: > On Mon, Nov 14, 2022 at 04:51:07PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 14, 2022 at 12:43:06PM +0100, Jiri Slaby (SUSE) wrote: > > > From: Andi Kleen <andi@firstfloor.org> > > > > > > Symbols referenced from assembler (either directly or e.f. from > > > DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because > > > they could end up in a different object file than the assembler. This > > > can lead to linker errors without this patch. > > > > > > So mark static call functions as __visible, namely static keys here. > > > > Why doesn't llvm-lto need this? > > It has an integrated assembler that can feed this information to the LTO > symbol table, while gas cannot do that. > > There was some discussion to extend the gcc top level asm syntax to > express external symbols, but so far it doesn't exist. Urgh, that's ugly too. Why does GCC insist on ugly solutions; clang has shown it can be done sanely, follow.
diff --git a/include/linux/static_call.h b/include/linux/static_call.h index df53bed9d71f..e629ab0c4ca3 100644 --- a/include/linux/static_call.h +++ b/include/linux/static_call.h @@ -182,7 +182,7 @@ extern long __static_call_return0(void); #define DEFINE_STATIC_CALL(name, _func) \ DECLARE_STATIC_CALL(name, _func); \ - struct static_call_key STATIC_CALL_KEY(name) = { \ + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ .func = _func, \ .type = 1, \ }; \ @@ -190,7 +190,7 @@ extern long __static_call_return0(void); #define DEFINE_STATIC_CALL_NULL(name, _func) \ DECLARE_STATIC_CALL(name, _func); \ - struct static_call_key STATIC_CALL_KEY(name) = { \ + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ .func = NULL, \ .type = 1, \ }; \ @@ -198,7 +198,7 @@ extern long __static_call_return0(void); #define DEFINE_STATIC_CALL_RET0(name, _func) \ DECLARE_STATIC_CALL(name, _func); \ - struct static_call_key STATIC_CALL_KEY(name) = { \ + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ .func = __static_call_return0, \ .type = 1, \ }; \ @@ -227,14 +227,14 @@ static inline int static_call_init(void) { return 0; } #define DEFINE_STATIC_CALL(name, _func) \ DECLARE_STATIC_CALL(name, _func); \ - struct static_call_key STATIC_CALL_KEY(name) = { \ + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ .func = _func, \ }; \ ARCH_DEFINE_STATIC_CALL_TRAMP(name, _func) #define DEFINE_STATIC_CALL_NULL(name, _func) \ DECLARE_STATIC_CALL(name, _func); \ - struct static_call_key STATIC_CALL_KEY(name) = { \ + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ .func = NULL, \ }; \ ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) @@ -288,7 +288,7 @@ static inline long __static_call_return0(void) #define __DEFINE_STATIC_CALL(name, _func, _func_init) \ DECLARE_STATIC_CALL(name, _func); \ - struct static_call_key STATIC_CALL_KEY(name) = { \ + __visible struct static_call_key STATIC_CALL_KEY(name) = { \ .func = _func_init, \ }