From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f66.google.com ([209.85.218.66]:33853 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbdFUHPL (ORCPT ); Wed, 21 Jun 2017 03:15:11 -0400 MIME-Version: 1.0 In-Reply-To: <20170621140445.4d6fd92a@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> From: Arnd Bergmann Date: Wed, 21 Jun 2017 09:15:09 +0200 Message-ID: Subject: Re: [PATCH 1/5] kbuild: thin archives final link close --whole-archives option Content-Type: text/plain; charset="UTF-8" Sender: linux-kbuild-owner@vger.kernel.org List-ID: To: Nicholas Piggin Cc: Masahiro Yamada , Linux Kbuild mailing list , linux-arch , Michal Marek , Linus Torvalds , Stephen Rothwell , kbuild test robot , Josh Triplett , Nicolas Pitre 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. 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. Arnd