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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 DEAC0C4332B for ; Tue, 9 Mar 2021 20:11:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7BF8652BE for ; Tue, 9 Mar 2021 20:11:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231484AbhCIULZ (ORCPT ); Tue, 9 Mar 2021 15:11:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229948AbhCIULJ (ORCPT ); Tue, 9 Mar 2021 15:11:09 -0500 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA3DBC06175F for ; Tue, 9 Mar 2021 12:11:06 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id p1so22900761edy.2 for ; Tue, 09 Mar 2021 12:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=B8/32gF659TPX/5eYINA0NMCAB5fgPljLbGnRiQdnYg=; b=HEUDvkWM2OFBGBu29IvnFBmfS+Gt2wCcZJ/ayUsAC2S6N/N3L0CEVfF8qcDiEZ0AXP yPaPwm2PuvzIkmjPIxP+8C2RzdkJafbpT21pQRp8egSQoDuXR9U+3h1eKNGpCPFNxyJL mLYAONdRQZayyLUWco/a6BRNXKafSz4PWZQoQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=B8/32gF659TPX/5eYINA0NMCAB5fgPljLbGnRiQdnYg=; b=bcsEg3KLrYXzA9f5cRK/mgnIzsKa+5IVfeVjDZMBArTN7P3I7LeVGpbOEnSQoTEuem LkpXLdliSf4NFeNee7cm7Xli6KAQQ0Nt2B+E1KjHnR2+ed5YxwRn0lLdLuIDMJZVeI57 0/SrocJQapf2aAvW9naTcxR5UKLTyJxz94oVTWWzKkODKrOPA6QPqQCOzYu/S9JO0wik JqceLtquWdAZDqtF+W6FWcw1M3UhdQe6bR6r0LPlza1GEgW4xSbZRXFmbDl9Sx5HSNbs 10GbKZm7WbqbqpZ//2Y4rr/L1mUEoAGLfqN/u2vAYvBN0I8GknqV7kAkfs/XFSTZ6Tfd CPhw== X-Gm-Message-State: AOAM533I8eiQX3VlC5v9NQF/0lOtysU1Qbx0hhWxtV4kwOo2LSnFvsFI 6LXoqR8c6XLD55lpLQxvZ/LSmA== X-Google-Smtp-Source: ABdhPJxaL4O3pJaCdNKg0mD1df/BfGKBvhhC7MuO0ig6LMNEdhKG/JlMLI/ZYh2CLH9LXjPM30SYAw== X-Received: by 2002:a05:6402:350f:: with SMTP id b15mr6186693edd.6.1615320665265; Tue, 09 Mar 2021 12:11:05 -0800 (PST) Received: from [192.168.1.149] ([80.208.71.248]) by smtp.gmail.com with ESMTPSA id t6sm9275838edq.48.2021.03.09.12.11.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Mar 2021 12:11:04 -0800 (PST) Subject: Re: [PATCH v2 3/4] kbuild: re-implement CONFIG_TRIM_UNUSED_KSYMS to make it work in one-pass To: Nicolas Pitre , Masahiro Yamada Cc: Linux Kbuild mailing list , Christoph Hellwig , Linus Torvalds , Jessica Yu , Linux Kernel Mailing List , linux-arch References: <20210309151737.345722-1-masahiroy@kernel.org> <20210309151737.345722-4-masahiroy@kernel.org> <354sr3np-67o8-oss9-813s-p2qoro06p4o@syhkavp.arg> <2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg> From: Rasmus Villemoes Message-ID: Date: Tue, 9 Mar 2021 21:11:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/2021 20.54, Nicolas Pitre wrote: > On Wed, 10 Mar 2021, Masahiro Yamada wrote: > >>> I'm not sure I do understand every detail here, especially since it is >>> so far away from the version that I originally contributed. But the >>> concept looks good. >>> >>> I still think that there is no way around a recursive approach to get >>> the maximum effect with LTO, but given that true LTO still isn't applied >>> to mainline after all those years, the recursive approach brings >>> nothing. Maybe that could be revisited if true LTO ever makes it into >>> mainline, and the desire to reduce the binary size is still relevant >>> enough to justify it. >> >> Hmm, I am confused. >> >> Does this patch change the behavior in the >> combination with the "true LTO"? >> >> Please let me borrow this sentence from your article: >> "But what LTO does is more like getting rid of branches that simply >> float in the air without being connected to anything or which have >> become loose due to optimization." >> (https://lwn.net/Articles/746780/) >> >> This patch throws unneeded EXPORT_SYMBOL metadata >> into the /DISCARD/ section of the linker script. >> >> The approach is different (preprocessor vs linker), but >> we will still get the same result; the unneeded >> EXPORT_SYMBOLs are disconnected from the main trunk. >> >> Then, the true LTO will remove branches floating in the air, >> right? >> >> So, what will be lost by this patch? > > Let's say you have this in module_foo: > > int foo(int x) > { > return 2 + bar(x); > } > EXPORT_SYMBOL(foo); > > And module_bar: > > int bar(int y) > { > return 3 * baz(y); > } > EXPORT_SYMBOL(bar); > > And this in the main kernel image: > > int baz(int z) > { > return plonk(z); > } > EXPORT_SYMBOLbaz); > > Now we build the kernel and modules. Then we realize that nothing > references symbol "foo". We can trim the "foo" export. But it would be > necessary to recompile module_foo with LTO (especially if there is > some other code in that module) to realize that nothing > references foo() any longer and optimize away the reference to bar(). But, does LTO even do that to modules? Sure, the export metadata for foo vanishes, so there's no function pointer reference to foo, but given that modules are just -r links, the compiler/linker can't really assume that the generated object won't later be linked with something that does require foo? At least for the simpler case of --gc-sections, ld docs say: '--gc-sections' ... This option can be set when doing a partial link (enabled with option '-r'). In this case the root of symbols kept must be explicitly specified either by one of the options '--entry', '--undefined', or '--gc-keep-exported' or by a 'ENTRY' command in the linker script. and I would assume that for LTO, --gc-keep-exported would be the only sane semantics (keep any external symbol with default visibility). Can you point me at a tree/set of LTO patches and a toolchain where the previous implementation would actually eventually eliminate bar() from module_bar? Rasmus