lkml.org 
[lkml]   [2021]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [GIT PULL] Modules updates for v5.12
    From
    Date
    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

    \
     
     \ /
      Last update: 2021-02-24 20:38    [W:4.309 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site