From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Piggin Subject: Re: [PATCH 1/5] kbuild: thin archives final link close --whole-archives option Date: Wed, 21 Jun 2017 20:38:24 +1000 Message-ID: <20170621203824.719ffdc5@roar.ozlabs.ibm.com> References: <20170609052417.561-1-npiggin@gmail.com> <20170609052417.561-2-npiggin@gmail.com> <20170619165100.3ce26d00@roar.ozlabs.ibm.com> <20170619182714.2cb60e17@roar.ozlabs.ibm.com> <20170620015205.329519b2@roar.ozlabs.ibm.com> <20170621124708.6bce7692@roar.ozlabs.ibm.com> <20170621140445.4d6fd92a@roar.ozlabs.ibm.com> <20170621191607.33c8db74@roar.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kbuild-owner@vger.kernel.org To: Arnd Bergmann Cc: Masahiro Yamada , Linux Kbuild mailing list , linux-arch , Michal Marek , Linus Torvalds , Stephen Rothwell , kbuild test robot , Josh Triplett , Nicolas Pitre List-Id: linux-arch.vger.kernel.org On Wed, 21 Jun 2017 12:21:16 +0200 Arnd Bergmann wrote: > On Wed, Jun 21, 2017 at 11:16 AM, Nicholas Piggin wrote: > > On Wed, 21 Jun 2017 09:15:09 +0200 > > Arnd Bergmann wrote: > > > >> On Wed, Jun 21, 2017 at 6:04 AM, Nicholas Piggin wrote: > >> > On Wed, 21 Jun 2017 12:29:33 +0900 > >> > Masahiro Yamada 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 > >> >> 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 can take a look at ARM and try to get it at least to parity with incremental link. Any particular config options required? > so we are fine as long as we enable THIN_ARCHIVES > and LD_DEAD_CODE_DATA_ELIMINATION at the same time > on ARM. Well the current proposal is to unconditionally enable it for all archs for 4.13. After that I'll submit patches to x86 and powerpc arch maintainers to allow LD_DEAD_CODE_DATA_ELIMINATION as an option. I guess you will do ARM and there have been MIPS guys looking at it too. That leaves a window of one release. ARM could unselect thin archives if necessary but I think it would be much better to enable it and flush out any toolchain and build issues before doing the LD_DCDE option. Disabling should be a last resort if we can't fix something in time for release. Thanks, Nick From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:33870 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbdFUKii (ORCPT ); Wed, 21 Jun 2017 06:38:38 -0400 Date: Wed, 21 Jun 2017 20:38:24 +1000 From: Nicholas Piggin Subject: Re: [PATCH 1/5] kbuild: thin archives final link close --whole-archives option Message-ID: <20170621203824.719ffdc5@roar.ozlabs.ibm.com> In-Reply-To: References: <20170609052417.561-1-npiggin@gmail.com> <20170609052417.561-2-npiggin@gmail.com> <20170619165100.3ce26d00@roar.ozlabs.ibm.com> <20170619182714.2cb60e17@roar.ozlabs.ibm.com> <20170620015205.329519b2@roar.ozlabs.ibm.com> <20170621124708.6bce7692@roar.ozlabs.ibm.com> <20170621140445.4d6fd92a@roar.ozlabs.ibm.com> <20170621191607.33c8db74@roar.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Masahiro Yamada , Linux Kbuild mailing list , linux-arch , Michal Marek , Linus Torvalds , Stephen Rothwell , kbuild test robot , Josh Triplett , Nicolas Pitre Message-ID: <20170621103824.65Rvoqx1nVPNAmwGcGaybUXl-QTRFh3IjQ7YI7B6FDU@z> On Wed, 21 Jun 2017 12:21:16 +0200 Arnd Bergmann wrote: > On Wed, Jun 21, 2017 at 11:16 AM, Nicholas Piggin wrote: > > On Wed, 21 Jun 2017 09:15:09 +0200 > > Arnd Bergmann wrote: > > > >> On Wed, Jun 21, 2017 at 6:04 AM, Nicholas Piggin wrote: > >> > On Wed, 21 Jun 2017 12:29:33 +0900 > >> > Masahiro Yamada 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 > >> >> 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 can take a look at ARM and try to get it at least to parity with incremental link. Any particular config options required? > so we are fine as long as we enable THIN_ARCHIVES > and LD_DEAD_CODE_DATA_ELIMINATION at the same time > on ARM. Well the current proposal is to unconditionally enable it for all archs for 4.13. After that I'll submit patches to x86 and powerpc arch maintainers to allow LD_DEAD_CODE_DATA_ELIMINATION as an option. I guess you will do ARM and there have been MIPS guys looking at it too. That leaves a window of one release. ARM could unselect thin archives if necessary but I think it would be much better to enable it and flush out any toolchain and build issues before doing the LD_DCDE option. Disabling should be a last resort if we can't fix something in time for release. Thanks, Nick