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

[Nicholas Piggin <npiggin@gmail.com>]

On Wed, 21 Jun 2017 12:29:33 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

> Hi Nicholas,
> 
> 
> 2017-06-21 11:47 GMT+09:00 Nicholas Piggin <npiggin@gmail.com>:
> > I wonder if the names could be a bit more descriptive?
> >
> > libs-y-liba
> > libs-y-builtin
> >
> > ?  
> 
> I do not have a strong opinion.  Either way sounds OK to me.
> If you like, I can fix it up.

I have nothing against it if you want to clean it up. You're the
maintainer so whatever you prefer :)

> I think you mentioned LD_DEAD_CODE_DATA_ELIMINATION is under way for
> ARM and x86.

Yes it seems to be quite successful. ARM and MIPS people are looking
at it, I have it working for powerpc and x86 quite easily. I will
send patches to arch maintainers if we get these thin archives changes
merged in the next window.

> If we can switch all architectures, lib.a will turn into built-in.o.  Correct?
> (I am not sure how difficult the global conversion is.)

Yes I think it should be no longer necessary.

The only problem with LD_DEAD_CODE_DATA_ELIMINATION is that it overloads
elf section names to pass data to the linker, so it's not 100% transparent.
In practice it's been very minor changes. On balance it will end up being
better than a whole lot of conditional compiling and linking workarounds
such as the one you mention below.

> 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@codeaurora.org>
> 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?

Thanks,
Nick