From patchwork Fri Aug 19 21:32:50 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 9290981 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4DC1B6077B for ; Fri, 19 Aug 2016 21:35:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4485F2957A for ; Fri, 19 Aug 2016 21:35:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 376E0295AA; Fri, 19 Aug 2016 21:35:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 57F3F295B1 for ; Fri, 19 Aug 2016 21:35:51 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1barPu-00013q-8y; Fri, 19 Aug 2016 21:33:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1barPt-00013A-4M for xen-devel@lists.xensource.com; Fri, 19 Aug 2016 21:33:29 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 78/BC-12460-82B77B75; Fri, 19 Aug 2016 21:33:28 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRWlGSWpSXmKPExsVybKJsh6569fZ wgw+dqhb3prxnd2D02N63iz2AMYo1My8pvyKBNWPCm9eMBX/5K86s/sPcwLict4uRi0NIYCqj xIWXbxkhnBlMEp+mnGLuYuTkYBMQl1jwYw4LSEJE4BiTxLUT75lBHGaBr1wSTz+uZAKpEhawk 7ix7CpYB4uAqsT+r2cZQWxeAQeJuV/Og8UlBOQkWn7sZgWxOQUcJU5P2sQGYgsB1XT2TwKyOY BqCiT2H46GKPeSWHTjEiuErSZx9dwm5gmMfAsYGVYxqhenFpWlFuka6SUVZaZnlOQmZuboGhq Y6uWmFhcnpqfmJCYV6yXn525iBAYKAxDsYPz+x+kQoyQHk5Ior5/a9nAhvqT8lMqMxOKM+KLS nNTiQ4wyHBxKErwhlUA5waLU9NSKtMwcYMjCpCU4eJREeCeApHmLCxJzizPTIVKnGBWlxHnNQ RICIImM0jy4NlicXGKUlRLmZQQ6RIinILUoN7MEVf4VozgHo5IwbzTIFJ7MvBK46a+AFjMBLe bl3wKyuCQRISXVwMh/vGU2Q9sXkSs9IYmZHR8Tww482CRw6Z2U3MXOu9PSwlROy7xYVZL4oGX lilep+V9UdCI3tP3rcdmZt6Hg3JTy5nVRHPM3ci5+7vvyo+rm7XNS5z3p2rf16yqxUzXxf7sj b37hCVuUzf2aJaXidfX8cMdVTvc6Dx94sUsqVSjkWUGx/veVB38psRRnJBpqMRcVJwIABTt5C o4CAAA= X-Env-Sender: mcgrof@kernel.org X-Msg-Ref: server-11.tower-206.messagelabs.com!1471642406!43201123!1 X-Originating-IP: [198.145.29.136] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 53172 invoked from network); 19 Aug 2016 21:33:27 -0000 Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.29.136) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 19 Aug 2016 21:33:27 -0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5052A2020F; Fri, 19 Aug 2016 21:33:23 +0000 (UTC) Received: from garbanzo.do-not-panic.com (c-73-15-241-2.hsd1.ca.comcast.net [73.15.241.2]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1BB82201F2; Fri, 19 Aug 2016 21:33:20 +0000 (UTC) From: mcgrof@kernel.org To: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, jpoimboe@redhat.com, bp@alien8.de, linux@arm.linux.org.uk, mhiramat@kernel.org, masami.hiramatsu.pt@hitachi.com, jbaron@akamai.com, heiko.carstens@de.ibm.com, ananth@linux.vnet.ibm.com, anil.s.keshavamurthy@intel.com, davem@davemloft.net, realmz6@gmail.com Date: Fri, 19 Aug 2016 14:32:50 -0700 Message-Id: <1471642385-5629-2-git-send-email-mcgrof@kernel.org> X-Mailer: git-send-email 2.7.0 In-Reply-To: <1471642385-5629-1-git-send-email-mcgrof@kernel.org> References: <1471642385-5629-1-git-send-email-mcgrof@kernel.org> X-Virus-Scanned: ClamAV using ClamSMTP Cc: gnomes@lxorguk.ukuu.org.uk, linux-ia64@vger.kernel.org, jkosina@suse.cz, benh@kernel.crashing.org, ming.lei@canonical.com, linux@rasmusvillemoes.dk, platform-driver-x86@vger.kernel.org, James.Bottomley@HansenPartnership.com, paul.gortmaker@windriver.com, paulus@samba.org, sparclinux@vger.kernel.org, mchehab@osg.samsung.com, linux-arch@vger.kernel.org, markus.heiser@darmarit.de, xen-devel@lists.xensource.com, msalter@redhat.com, linux-sh@vger.kernel.org, mpe@ellerman.id.au, x86@kernel.org, fontana@sharpeleven.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, dvhart@infradead.org, dwmw2@infradead.org, linux-xtensa@linux-xtensa.org, pali.rohar@gmail.com, keescook@chromium.org, arnd@arndb.de, jani.nikula@intel.com, will.deacon@arm.com, rusty@rustcorp.com.au, rostedt@goodmis.org, acme@redhat.com, ak@linux.intel.com, andriy.shevchenko@linux.intel.com, mcb30@ipxe.org, linux-kbuild@vger.kernel.org, alan@linux.intel.com, jgross@suse.com, chris@zankel.net, pebolle@tiscali.nl, tony.luck@intel.com, ananth@in.ibm.com, jcmvbkbc@gmail.com, gregkh@linuxfoundation.org, luto@amacapital.net, "Luis R. Rodriguez" , mmarek@suse.com, david.vrabel@citrix.com, jolsa@kernel.org, andrew.cooper3@citrix.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, korea.drzix@gmail.com Subject: [Xen-devel] [PATCH v4 01/16] x86: remove LTO_REFERENCE_INITCALL() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP From: "Luis R. Rodriguez" The setup for LTO never made it upstream, and although this has some users, this is now really old stuff for a gcc 4.7 LTO problem. We know that at least LTO_REFERENCE_INITCALL() work around can be removed if LTO is not supported on v4.7 anymore. As per Andi the DISABLE_LTO and LTO_CFLAGS are still neeeded though. v3: added to this series, removing LTO_REFERENCE_INITCALL() justifies that other future similar macros do not need a respective LTO_REFERENCE_INITCALL() on them therefore simplifying new code. Acked-by: Andi Kleen Signed-off-by: Luis R. Rodriguez --- include/linux/init.h | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index 1e5c131d5c9a..aa662ad80d9c 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -151,23 +151,6 @@ extern bool initcall_debug; #ifndef __ASSEMBLY__ -#ifdef CONFIG_LTO -/* Work around a LTO gcc problem: when there is no reference to a variable - * in a module it will be moved to the end of the program. This causes - * reordering of initcalls which the kernel does not like. - * Add a dummy reference function to avoid this. The function is - * deleted by the linker. - */ -#define LTO_REFERENCE_INITCALL(x) \ - ; /* yes this is needed */ \ - static __used __exit void *reference_##x(void) \ - { \ - return &x; \ - } -#else -#define LTO_REFERENCE_INITCALL(x) -#endif - /* initcalls are now grouped by functionality into separate * subsections. Ordering inside the subsections is determined * by link order. @@ -180,8 +163,7 @@ extern bool initcall_debug; #define __define_initcall(fn, id) \ static initcall_t __initcall_##fn##id __used \ - __attribute__((__section__(".initcall" #id ".init"))) = fn; \ - LTO_REFERENCE_INITCALL(__initcall_##fn##id) + __attribute__((__section__(".initcall" #id ".init"))) = fn; /* * Early initcalls run before initializing SMP.