Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <YDUibKAt5tpA1Hxs@gunter> <CAHk-=wipCbbXswcFvnrGae01H54dY1+XoaL+9YaiU71zGzko3Q@mail.gmail.com>
 <CAHk-=wh8vHL43v7GWK9MWrWitSmOmrEw1B0AJD9CrhBc4FvpxA@mail.gmail.com>
 <CAHk-=wiuoRKa=F3txoVHvnca+H=7gJyL3SFYwd3549v-sa0+QQ@mail.gmail.com>
 <20210223200130.GA8059@lst.de> <CAHk-=wj27tmZBzFRTZTAEPd6eRBzP5xCkQM+1cuSx7vzv8K4=g@mail.gmail.com>
 <YDYPWAtoDpyD9D4Z@gunter> <CAK7LNAQUL4qEgk97z0WfagVDgGAARzj8hqFyrC2wnPjiLduEoQ@mail.gmail.com>
 <cb28abc8-5c4c-90c2-e3f2-a939ff507a8b@prevas.dk> <CAK7LNASv-pWVdztiD1-VCHCnOqZ6j=J6ra5cEdiUkmM9E8fHWQ@mail.gmail.com>
 <a2d84bf6-f753-92f6-7613-38391e65af85@prevas.dk>
In-Reply-To: <a2d84bf6-f753-92f6-7613-38391e65af85@prevas.dk>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri, 26 Feb 2021 03:37:26 +0900
Message-ID: <CAK7LNATsQ9mnV-5z04fCK=wMw+eXCyVLruCq3too_oqw3YMK+Q@mail.gmail.com>
Subject: Re: [GIT PULL] Modules updates for v5.12
To:     Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc:     Jessica Yu <jeyu@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Christoph Hellwig <hch@lst.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        =?UTF-8?Q?=EF=BF=BCMiroslav_Benes?= <mbenes@suse.cz>,
        Emil Velikov <emil.l.velikov@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Feb 26, 2021 at 1:19 AM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 25/02/2021 16.49, Masahiro Yamada wrote:
> > On Thu, Feb 25, 2021 at 4:36 AM Rasmus Villemoes
> > <rasmus.villemoes@prevas.dk> wrote:
> >>
> >> On 24/02/2021 15.40, Masahiro Yamada wrote:
> >
> >
> > Good insight.
> > Actually, I came up with the same idea last night, and had started
> > the implementation background.
> > I needed sleep before completing the patch set, but
> > now it is working as far as I tested.
> >
> > BTW,
> > KEEP(*(SORT(___ksymtab+foo ___ksymtab+bar ___ksymtab+baz))
> > is a syntax error.
> >
>
> ah, ok, didn't test anything, just threw it out there in case somebody
> wanted to see if it was doable.
>
> Is that a limitation of SORT? The ld docs say
>
>    There are two ways to include more than one section:
>      *(.text .rdata)
>      *(.text) *(.rdata)
> The difference between these is the order in which the '.text' and
> '.rdata' input sections will appear in the output section.
>
> so there shouldn't be a problem mentioning more than one section name?


    KEEP(*(foo bar))
and
    SORT(*(foo bar))

are both syntax error.


I think having multiple entries in KEEP() / SORT()
is sensible, but unfortunately the linker rejects this form.


> >> If LD_DEAD_CODE_DATA_ELIMINATION was more widely supported (and I was
> >> surprised to see that it's not even available on arm or x86) one could
> >> also play another game, dropping the KEEP()s and instead create a linker
> >> script snippet containing EXTERN(__ksymtab_foo __ksymtab_bar ...),
> >> referencing the "struct kernel_symbol" elements themselves rather than
> >> the singleton sections they reside in.
> >
> > Do you mean LD_DEAD_CODE_DATA_ELIMINATION must be enabled by default
> > to do this?
> >
>
> No, but without LD_DEAD_CODE_DATA_ELIMINATION, I don't see much point of
> the TRIM_UNUSED_KSYMS. Yes, the export_symbol metadata itself vanishes,
> but the actual functions remain in the image. Conversely, with modules
> enabled, LD_DEAD_CODE_DATA_ELIMINATION can't do much when almost all of
> the kernel can be built modular so almost extern interface is an
> EXPORT_SYMBOL. At least, that's what I see for a ppc target with a
> somewhat trimmed-down .config, combining the two gives much more space
> saving than the sum of what each option does:
>
> $ size vmlinux.{vanilla,trim,dead,trim-dead}
>    text    data     bss     dec     hex filename
> 6197380 1159488  121732 7478600  721d48 vmlinux.vanilla
> 6045906 1159440  121732 7327078  6fcd66 vmlinux.trim
> 6087316 1137284  120476 7345076  7013b4 vmlinux.dead
> 5675370 1101964  115180 6892514  692be2 vmlinux.trim-dead
>
> Anyway, that was just an aside, probably the above ___ksymtab+foo thing
> will work just fine.
>
> Rasmus


Make sense.

The combination of LD_DEAD_CODE_DATA_ELIMINATION and
TRIM_UNUSED_KSYMS is more powerful than
the stand-alone use of TRIM_UNUSED_KSYMS.


I just expected the combination of LTO and TRIM_UNUSED_KSYMS
would be even more powerful...

Unfortunately, Clang LTO which lands in this MW
cannot trim any code. So, it is useless for the
purpose of eliminating unreachable code.


--
Best Regards
Masahiro Yamada