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=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 6BEF8C433DB for ; Wed, 10 Mar 2021 20:52:36 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 D89EB64FB3 for ; Wed, 10 Mar 2021 20:52:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D89EB64FB3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kdYoT5CxG8CFOVaEbn5l3vhHanO3z3wiNrpmnqcwjlo=; b=h9Kl6BxbAM53Cnwn+dXquk0y+ Wx+Y1e/CnJ5lpxZoee/Pxy8JXyP3LvCSWCjausCKiFLUl+MQz+rvt0WsizawzLC6QeRYl9w2OgjeE Ohq8M7WmTG4lS309OWKf5+4yGbyk0riHkiOoc8niO1P9D9jQ4rOAIUCLrsPvlYc4dXqJDjcoGRgBx jSK5YsxWGcQbT3YnVQCrq5ZD7MUKIwzU8p4+fipjfhGUg5//ITJ5ss0/dliph+kVJA7u933snflXs EF0RSmfErzx1ZIOSOz/NNuoDC+PHZNVE6oE7+L6nXHU2R13O9hzs7S9VKEJrDOuvCiZKei3QeSvMT 9PBFMMn8Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK5n8-007hJN-CU; Wed, 10 Mar 2021 20:50:50 +0000 Received: from conssluserg-01.nifty.com ([210.131.2.80]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lK5n0-007hIT-J9 for linux-arm-kernel@lists.infradead.org; Wed, 10 Mar 2021 20:50:47 +0000 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (authenticated) by conssluserg-01.nifty.com with ESMTP id 12AKoKDe023941 for ; Thu, 11 Mar 2021 05:50:20 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 12AKoKDe023941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1615409420; bh=vkspD6XwG9rG1Ytw7ZTJwsuuvU9BzfeWtF/EO7NZxcw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jlhT/zXInqDRocnQcd25cXigTXn4U2J5+fAzdADlEzZd8eepQGJbU0DMgasu75Hb3 fVtK6bUOAVx2Lkl4r/V+Pk3w2jX8bgv2ZVEC/crxRxYxnM+O7n7SC1zS87ne/jIQEM keGpGgtFrPrXKTgpuZBGBAmFBjraOrSOLnpXIYfsTdDSuP1bC/KX25rhezxpcYXPKd BGPTu7oa2OJ486rB99VUBeSblueGjmfLBKADwgOXEb5TVNIVb0AWwcKXRShWJA5VQi SWHgbK9Bqt+MupI3DMfVj4O8oXB43BuUxBQ+NVAf5u6v5i7TzCK3C81GCwS0dTIXhC JTHbbVDp9bdwQ== X-Nifty-SrcIP: [209.85.214.175] Received: by mail-pl1-f175.google.com with SMTP id d23so5879202plq.2 for ; Wed, 10 Mar 2021 12:50:20 -0800 (PST) X-Gm-Message-State: AOAM533nVaofQVGgcyvE5RSRm7z0y2ltM3YfyA5L1fcnN+XLN/rc2IDh FuPwES7XoU948+gITH3xdHQxf9DV55+ic5oNSAc= X-Google-Smtp-Source: ABdhPJzQ1MlUUYOx6ctKUbbI1vw5urT2osjwH23aqKEtVncC4vqvQPiS/CeJIOS6U2Zq/jZ8U8KtjFAkVIBOLG1H3Pk= X-Received: by 2002:a17:902:8ec9:b029:e6:c5e:cf18 with SMTP id x9-20020a1709028ec9b02900e60c5ecf18mr4523952plo.47.1615409419575; Wed, 10 Mar 2021 12:50:19 -0800 (PST) MIME-Version: 1.0 References: <20210225112122.2198845-1-arnd@kernel.org> <20210226211323.arkvjnr4hifxapqu@google.com> <1614559739.p25z5x88wl.astroid@bobo.none> In-Reply-To: <1614559739.p25z5x88wl.astroid@bobo.none> From: Masahiro Yamada Date: Thu, 11 Mar 2021 05:49:42 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION To: Nicholas Piggin Cc: Arnd Bergmann , Fangrui Song , Ard Biesheuvel , Arnd Bergmann , Andrew Scull , Mark Brown , Catalin Marinas , clang-built-linux , David Brazdil , Geert Uytterhoeven , Ionela Voinescu , Kees Cook , Kristina Martsenko , Linux ARM , "linux-kernel@vger.kernel.org" , Mark Rutland , Marc Zyngier , Nathan Chancellor , Nick Desaulniers , Vincenzo Frascino , Will Deacon , Nicolas Pitre X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_205043_487247_75A8E5BC X-CRM114-Status: GOOD ( 48.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote: > > 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 > I tested LD_DEAD_CODE_DATA_ELIMINATION for the latest kernel. I added an unused function, this_func_is_unused(), then built the ppc kernel with LD_DEAD_CODE_DATA_ELIMINATION. It remained in vmlinux. masahiro@oscar:~/ref/linux$ echo 'void this_func_is_unused(void) {}' >> kernel/cpu.c masahiro@oscar:~/ref/linux$ export CROSS_COMPILE=/home/masahiro/tools/powerpc-10.1.0/bin/powerpc-linux- masahiro@oscar:~/ref/linux$ make ARCH=powerpc defconfig masahiro@oscar:~/ref/linux$ ./scripts/config -e EXPERT masahiro@oscar:~/ref/linux$ ./scripts/config -e LD_DEAD_CODE_DATA_ELIMINATION masahiro@oscar:~/ref/linux$ ~/tools/powerpc-10.1.0/bin/powerpc-linux-nm -n vmlinux | grep this_func c000000000170560 T .this_func_is_unused c000000001d8d560 D this_func_is_unused masahiro@oscar:~/ref/linux$ grep DEAD_CODE_ .config CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y If I remember correctly, LD_DEAD_CODE_DATA_ELIMINATION dropped unused functions when I tried it last time. I also tried arm64 with a HAVE_LD_DEAD_CODE_DATA_ELIMINATION hack. The result was the same. Am I missing something? -- Best Regards Masahiro Yamada _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel