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? > Any other ideas for > how this could be solved? We used to have a Kconfig symbol > for each file, but those would frequently get out of sync. Not really sure. Possibly the way to do it would be to plumb lib-y through drivers/ as well (like obj-y is) so they can be linked on their own for the final vmlinux link. But that may be quite a bit of churn, so it may be better to hold such changes until we see how LD_DEAD_CODE_DATA_ELIMINATION works out. 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
