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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

>> 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.

I see.

       Arnd
--
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



[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux