Re: [PATCH 1/5] kbuild: thin archives final link close --whole-archives option

[Stephen Boyd <sboyd@codeaurora.org>]

On 06/21, Arnd Bergmann wrote:
> On Wed, Jun 21, 2017 at 2:02 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> > On Wed, 21 Jun 2017 13:32:17 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> On Wed, Jun 21, 2017 at 1:10 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> >> > On Wed, 21 Jun 2017 12:49:10 +0200
> >> > Arnd Bergmann <arnd@arndb.de> wrote:
> >> >
> >> >> On Wed, Jun 21, 2017 at 12:38 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> >> >> > On Wed, 21 Jun 2017 12:21:16 +0200
> >> >> > Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> >
> >> >>
> >> >> I'm building on top of yesterday's linux-next at the moment,
> >> >> with a number of my own patches applied
> >> >>
> >> >> > I can take a look at ARM and try to get it at least to parity with
> >> >> > incremental link. Any particular config options required?
> >> >>
> >> >> This is the patch I am testing with:
> >> >>
> >> >> https://pastebin.com/HQuhCEmK
> >> >> I have not looked at that in a while, no idea if it works, or
> >> >> if it has known problems.
> >> >>
> >> >> I last posted the patch in March for discussion:
> >> >>
> >> >> https://patchwork.kernel.org/patch/9626207/
> >> >
> >> > Well I just mean the stuff now in kbuild/thin-ac, not the LD_DCDE.
> >> > Just want to try getting thin archives up to a point where there are
> >> > no serious regressions first.
> >>
> >> For my build testing, I have now reverted most of my patch and only
> >> left the 'select THIN_ARCHIVES'. I'll let you know if I run into problems.
> >
> > Okay. Currently with the patches in the kbuild tree, thin archives
> > actually does better than incremental linking for ARM (defconfig).
> >
> > 11651574        6090952  418616 18161142        1151df6 vmlinux.thinarc
> > 11656118        6095208  418952 18170278        11541a6 vmlinux.inc
> >
> > In mainline, thin archives is sub-optimal for lib-y libraries (just
> > pulls them all in). But now that I test it, even that is better than
> > incremental linking for ARM:
> >
> > 11653926        6090888  418620 18163434        11526ea vmlinux.thinarc
> >
> > I haven't grabbed that "clk: sunxi-ng: Move all clock types to a library"
> > patch yet to check. What tree is it in? I wonder if I could convince you
> > to drop that for now and bring it up on linux-kernel/linux-kbuild? I
> > think it's quite reasonable to reduce Kconfig hell of very fine grained
> > conditional compilation/linking if we can make the toolchain do it for
> > us. So we should consider how to support it nicely rather than having
> > such hacks IMO.
> 
> [adding Maxime and Stephen to cc]
> 
> Stephen,
> 
> The hack has come to bite us after all, with Nick's proposed change to
> CONFIG_THIN_ARCHIVES for all architectures, the entire lib.a file will
> end up being linked into each kernel that enables the directory.
> 
> I'm out of other ideas for fixing it, so it seems better to revert back to
> individual Kconfig options. Once we enable
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION (which is the
> next step after CONFIG_THIN_ARCHIVES), we can simply list
> all files, and the linker will drop all unused functions by itself.
> 

Ok. Can you send a revert patch to the list with some information
on why we can't do the hack anymore and also Cc lkml/kbuild
lists? The commit is in linux-next now as commit 06e226c7fb23
(clk: sunxi-ng: Move all clock types to a library, 2017-06-02).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project