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.7 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 9AD7FC433E0 for ; Mon, 1 Mar 2021 01:13:08 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4142E64E54 for ; Mon, 1 Mar 2021 01:13:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4142E64E54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:MIME-Version:In-Reply-To:References:To: Subject:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FHzrMW1yfmt7pY0yOgqRM9hQdu4tYzLPpbKy+H8Obnc=; b=O5NoY2knpFQq7rL1z3JsfnD2H Wnw2oTUAV9xIJPQu52X82dJfMUAPRzI1SAO8hgCyjvTENkOj/h+ouc39vGWKYCnGh2BSJQYZEJGel LXi8r1yedb2I+NrG3uPPQVUkUrUGVbBOVIbK0kl1szM/zNbzgHj4jXGvqAhLpf9/eI/7e0vSZQJ7V QC5961PzAwHIfQLoRKG3GFQy3srOqUyO4hGlLGA7+vooKRtKAXdWFzxlWxFeZVkuAX2gTUQb8LpKA JFv1hYYse1R6CC71WOfMHPOR3vYWxk6cdYi2pgWM1rXWTwO60i8x2mrdss+2l2vXvJjcm2F0NAiSZ /Hj4DW8gw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lGX5z-0002wj-D3; Mon, 01 Mar 2021 01:11:35 +0000 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lGX5w-0002wO-3d for linux-arm-kernel@lists.infradead.org; Mon, 01 Mar 2021 01:11:33 +0000 Received: by mail-pj1-x1032.google.com with SMTP id t9so9972854pjl.5 for ; Sun, 28 Feb 2021 17:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=lt0oVa4TTqOxC4dz7vJKEQu8Xc7A+35tptwF7QqK3/k=; b=m0FkE2krnamYFeX1Pti0Fl1Ein+4gSp9e9e/va840QQyrijFm1iLewX6PGXF9ibg8n s3GMnM4wODiOLo9FGyv8WP7YT9ws4Nz/G4WLQek+pg9mpQmaHCH7hRoPFQmI6rZI9AR2 XGdnUYLaSS2E8CeGEeAoxUG9Q5dAGN1ID+Kx2mRbGr2HMlvLZez5AEqF7TOB9MoUbmZu BK6iZm6XLsCcCkDH1nRsy6uWEewKtVpFd/zXtYvEhc7RgDRoNXv/MGp5/9CXfMSuHTTf UMU8sEdAsEdkjekgqoyNXscD00gPQ36O1F03EZic5KRdL7TYgxbgLTwpBCP/6+tUObFu PlTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=lt0oVa4TTqOxC4dz7vJKEQu8Xc7A+35tptwF7QqK3/k=; b=lvcmYOXQvAj4LYuzKAdyH+nIhNcv0xHQnelfsEgGznFrHxStdBkz0Qnk8jQMo8VT+l so2NYP+1Rtn32S9KNCXT8LVna/ji2TtmTLidWALFOIo6TRS5kK65A/xB/ijGNQP4EVMd bTpRYXYdh1e0ReBeZVI2GJ8OEeSSaQBViZ46T/u2E84Zjt3nLs4+6VhUygbvAGOA6olE wDVIRw/3fW8vroNoYOS2miXLbf4/hkxGZ0DHWEpaygWAp5A1NQcLB0mtLJPp2n5gOjPG jV8WYoU2QvhEZlubfZsfNW3Wm/dCUOfRqKKz/xVtFkOE1ffshxJxAYr05w1VbwylzTSs /+BQ== X-Gm-Message-State: AOAM532n9DEUSbKHvwRX5RsQPeVYpyPozy1CV13Bhydkzuqz26C5N9o4 PxygJOfZBEAr03zDJaxgjjU= X-Google-Smtp-Source: ABdhPJzRbhBimuqvZNSXpcezQzmyQzJVRzPgweHg3FMIK4k3Dxf5yo6rME5JvUFz6xZ8Qyts9jDNTg== X-Received: by 2002:a17:90a:16d7:: with SMTP id y23mr15152020pje.227.1614561088230; Sun, 28 Feb 2021 17:11:28 -0800 (PST) Received: from localhost (58-6-239-121.tpgi.com.au. [58.6.239.121]) by smtp.gmail.com with ESMTPSA id c15sm14911942pfj.170.2021.02.28.17.11.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Feb 2021 17:11:27 -0800 (PST) Date: Mon, 01 Mar 2021 11:11:22 +1000 From: Nicholas Piggin Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION To: Arnd Bergmann , Fangrui Song References: <20210225112122.2198845-1-arnd@kernel.org> <20210226211323.arkvjnr4hifxapqu@google.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <1614559739.p25z5x88wl.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210228_201132_226106_6BFF3832 X-CRM114-Status: GOOD ( 27.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Vincenzo Frascino , Geert Uytterhoeven , Arnd Bergmann , Nicolas Pitre , Catalin Marinas , Nick Desaulniers , "linux-kernel@vger.kernel.org" , Kristina Martsenko , Nathan Chancellor , clang-built-linux , Will Deacon , Mark Brown , Andrew Scull , Marc Zyngier , David Brazdil , Ionela Voinescu , Ard Biesheuvel , Linux ARM , Kees Cook Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm: > On Fri, Feb 26, 2021 at 10:13 PM 'Fangrui Song' via Clang Built Linux > wrote: >> >> For folks who are interested in --gc-sections on metadata sections, >> I want to bring you awareness of the implication of __start_/__stop_ symbols and C identifier name sections. >> You can see https://github.com/ClangBuiltLinux/linux/issues/1307 for a summary. >> (Its linked blog article has some examples.) >> >> In the kernel linker scripts, most C identifier name sections begin with double-underscore __. >> Some are surrounded by `KEEP(...)`, some are not. >> >> * A `KEEP` keyword has GC root semantics and makes ld --gc-sections ineffectful. >> * Without `KEEP`, __start_/__stop_ references from a live input section >> can unnecessarily retain all the associated C identifier name input >> sections. The new ld.lld option `-z start-stop-gc` can defeat this rule. >> >> As an example, a __start___jump_table reference from a live section >> causes all `__jump_table` input section to be retained, even if you >> change `KEEP(__jump_table)` to `(__jump_table)`. >> (If you change the symbol name from `__start_${section}` to something >> else (e.g. `__start${section}`), the rule will not apply.) > > I suspect the __start_* symbols are cargo-culted by many developers > copying stuff around between kernel linker scripts, that's certainly how I > approach making changes to it normally without a deeper understanding > of how the linker actually works or what the different bits of syntax mean > there. > > I see the original vmlinux.lds linker script showed up in linux-2.1.23, and > it contained > > + . = ALIGN(16); /* Exception table */ > + __start___ex_table = .; > + __ex_table : { *(__ex_table) } > + __stop___ex_table = .; > + > + __start___ksymtab = .; /* Kernel symbol table */ > + __ksymtab : { *(__ksymtab) } > + __stop___ksymtab = .; > > originally for arch/sparc, and shortly afterwards for i386. The magic > __ex_table section was first used in linux-2.1.7 without a linker > script. It's probably a good idea to try cleaning these up by using > non-magic start/stop symbols for all sections, and relying on KEEP() > instead where needed. > >> There are a lot of KEEP usage. Perhaps some can be dropped to facilitate >> ld --gc-sections. > > I see a lot of these were added by Nick Piggin (added to Cc) in this commit: > > commit 266ff2a8f51f02b429a987d87634697eb0d01d6a > Author: Nicholas Piggin > Date: Wed May 9 22:59:58 2018 +1000 > > kbuild: Fix asm-generic/vmlinux.lds.h for LD_DEAD_CODE_DATA_ELIMINATION > > KEEP more tables, and add the function/data section wildcard to more > section selections. > > This is a little ad-hoc at the moment, but kernel code should be moved > to consistently use .text..x (note: double dots) for explicit sections > and all references to it in the linker script can be made with > TEXT_MAIN, and similarly for other sections. > > For now, let's see if major architectures move to enabling this option > then we can do some refactoring passes. Otherwise if it remains unused > or superseded by LTO, this may not be required. > > Signed-off-by: Nicholas Piggin > Signed-off-by: Masahiro Yamada > > which apparently was intentionally cautious. > > Unlike what Nick expected in his submission, I now think the annotations > will be needed for LTO just like they are for --gc-sections. Yeah I wasn't sure exactly what LTO looks like or how it would work. I thought perhaps LTO might be able to find dead code with circular / back references, we could put references from the code back to these tables or something so they would be kept without KEEP. I don't know, I was handwaving! I managed to get powerpc (and IIRC x86?) working with gc sections with those KEEP annotations, but effectiveness of course is far worse than what Nicolas was able to achieve with all his techniques and tricks. But yes unless there is some other mechanism to handle these tables, then KEEP probably has to stay. I suggest this wants a very explicit and systematic way to handle it (maybe with some toolchain support) rather than trying to just remove things case by case and see what breaks. I don't know if Nicolas is still been working on his shrinking patches recenty but he probably knows more than anyone about this stuff. Thanks, Nick _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel