On Wed, 21 Jun 2017 12:49:10 +0200 Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Wed, Jun 21, 2017 at 12:38 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > On Wed, 21 Jun 2017 12:21:16 +0200 > > Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > >> On Wed, Jun 21, 2017 at 11:16 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > >> > On Wed, 21 Jun 2017 09:15:09 +0200 > >> > Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > > >> >> On Wed, Jun 21, 2017 at 6:04 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > >> >> > On Wed, 21 Jun 2017 12:29:33 +0900 > >> >> > Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: > >> >> > >> >> >> BTW, I saw abuse of lib.a in > >> >> >> https://patchwork.kernel.org/patch/9768439/ > >> >> >> > >> >> >> I see it in linux-next. > >> >> >> > >> >> >> commit 06e226c7fb233f676b01b144d0b321ebe510fdcd > >> >> >> Author: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> > >> >> >> Date: Fri Jun 2 15:30:06 2017 -0700 > >> >> >> > >> >> >> clk: sunxi-ng: Move all clock types to a library > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> Now drivers/clk/sunxi-ng/lib.a > >> >> >> will go into thin archives. > >> >> >> The result might be different from what they expect... > >> >> > > >> >> > Yes I see. With thin archives, that is just going to cause the > >> >> > same behaviour as built-in.o (everything will be linked). So the > >> >> > build should not break, but they won't get savings. > >> >> > > >> >> > Does it even save space with incremental linking? If the lib.a gets > >> >> > linked into drivers/built-in.o, I wonder what happens then? > >> >> > >> >> Ah, too bad. I thought we had found a way to use a library correctly > >> >> here, but I just verified that indeed all the just gets linked into built-in.o > >> >> > >> >> I played around with it some more now, but without success: if I > >> >> build sunxi-ng as a loadable module (using a few modifications), > >> >> then the unneeded objects from lib.a are dropped as I had hoped, > >> >> but for built-in code we now always include everything. > >> >> > >> >> I suppose that we can ignore this once we get > >> >> LD_DEAD_CODE_DATA_ELIMINATION enabled on ARM, but > >> >> until then, we have a code size regression. > >> > > >> > I didn't follow the thread there, is it a regression caused by > >> > thin archives, or just by removing the Kconfig symbol from each > >> > file? > >> > >> I thought it was the latter, but actually it only happens with thin > >> archives, > > > > Is this including these changes now in the kbuild tree? > > 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. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
