Re: [GIT PULL] Modules updates for v5.12

[Rasmus Villemoes <rasmus.villemoes@prevas.dk>]

On 24/02/2021 15.40, Masahiro Yamada wrote:
> On Wed, Feb 24, 2021 at 5:33 PM Jessica Yu <jeyu@kernel.org> wrote:
>>
>> +++ Linus Torvalds [23/02/21 12:03 -0800]:
>>> On Tue, Feb 23, 2021 at 12:01 PM Christoph Hellwig <hch@lst.de> wrote:
>>>>
>>>> Does your build now enable TRIM_UNUSED_KSYMS but previously didn't by
>>>> chance?
>>>
>>> Crossed emails.
>>>
>>> This is plain "make allmodconfig", so yes, now it will enable TRIM_UNUSED_KSYMS.
>>>
>>> This is unacceptably slow. If that symbol trimming takes 30% of the
>>> whole kernel build time, it needs to be fixed or removed.
>>
>> [ Adding Masahiro to CC ]
>>
>> It looks like CONFIG_TRIM_UNUSED_KSYMS had been hiding behind
>> CONFIG_UNUSED_SYMBOLS all this time, and once the EXPORT_UNUSED_SYMBOL
>> stuff was removed, it exposed that option to be selected by
>> allyesconfig. That option had previously caused build issues on
>> powerpc on linux-next, so I had temporarily marked that as BROKEN on
>> powerpc until Masahiro's fix landed in linux-next. I was not aware of
>> the additional build slowdown issue :/ In any case, Christoph's
>> suggestion to invert the option sounds reasonable, since the mips
>> defconfig selects it, it does not seem totally unused.
> 
> 
> TRIM_UNUSED_KSYMS builds the tree twice by its concept.
> 
> [1] 1st build
>       At this point of time, we do not know  which EXPORT_SYMBOL()
>       is needed. So, EXPORT_SYMBOL() is enabled, or noop'ed
>       based on the temporal guess.
>       (in the fresh build, EXPORT_SYMBOL() are all nooped.)
> 
> [2]  Get the list of symbols needed to resolve all symbol references.
>      (this information is collected in include/generated/autoksyms.h)
> 
> [3] 2nd build
>      Rebuild the objects whose EXPORT_SYMBOL()
>      must be flipped.

I'm thinking we should be able to generate a linker script snippet from
[2] and use that when linking vmlinux, so there's no recursion and no
rebuild of individual .o files (and all the __cond_export_sym trickery
goes away).

The ksymtab entry for foo is already emitted in its own ___ksymtab+foo
section (or ___ksymtab_gpl+foo). So if the sorted list of undefined
symbols listed in the .mod files (plus the whitelist) consist of foo,
bar and baz, generate a header to be included by vmlinux.lds.h that says

#define KSYMTAB_SECTIONS \
  ___ksymtab+foo \
  ___ksymtab+bar \
  ___ksymtab+baz \

#define KSYMTAB_GPL_SECTIONS \
  ___ksymtab_gpl+foo \
  ___ksymtab_gpl+bar \
  ___ksymtab_gpl+baz \

with a !CONFIG_TRIM_UNUSED_KSYMS definition of these that just says

#define KSYMTAB_SECTIONS ___ksymtab+*
#define KSYMTAB_GPL_SECTIONS ___ksymtab_gpl+*

and use that

__ksymtab    AT(ADDR(__ksymtab) - LOAD_OFFSET) {		\
	__start___ksymtab = .;					\
	KEEP(*(SORT(KSYMTAB_SECTIONS)))				\
	__stop___ksymtab = .;					\

Only one of ___ksymtab+foo and ___ksymtab_gpl+foo will exist, but that
doesn't matter (it's really no different from the fact that many files
(i.e. the * before "(SORT") don't contain any section matching
___ksymtab_gpl+*).

We may then have to add another discard section to put the remaining
___ksymtab_gpl+* sections in, but that's fine as long as that stanza
just appears later in the linker script.

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.

Rasmus