On Fri, Feb 26, 2021 at 1:19 AM Rasmus Villemoes
<rasmus.villem...@prevas.dk> wrote:
>
> On 25/02/2021 16.49, Masahiro Yamada wrote:
> > On Thu, Feb 25, 2021 at 4:36 AM Rasmus Villemoes
> > <rasmus.villem...@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
