Re: RFC: Support link with mixed IR/non-IR objects

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 8 May 2012, Alan Modra wrote:

> On Mon, May 07, 2012 at 04:18:49PM -0700, Andi Kleen wrote:
> > The Linux
> > kernel absolutely needs this feature to build with LTO. The build
> > system heavily
> > relies on ld -r and it would be very intrusive to avoid this.
>
> I've been saying this for a long time, but I'll try once more.  It
> would be a good thing if the kernel build stopped using ld -r.  ld -r
> is not the right tool for packaging object files.  You get the
> following undesirable behaviour from ld -r:
>
> - -ffunction-sections code may be reorganized, losing cache locality.
>   eg. two different files each with a static "setup" function will
>   have those functions placed together in the same section.
> - Combining sections prevents --gc-sections from working as well as it
>   could.
> - On targets like powerpc64, ld -r may cause overflow of the .toc
>   section in the resulting relocatable object file.  If the files were
>   left separate, the final ld could cope by generating multiple .toc
>   sections.
>
> Now we also have
> - ld -r doesn't work with LTO.
>
> I had hoped that this would finally wake up kernel developers.

I understand and agree with the sentiment but I think we need to
create a usable alternative in order for that to happen.

Linux can't use "ar" as it is, because it (and gold and gld,
when passed an .a) doesn't make sure to include objects with the
kernel flavor of cdtors in the final image, and you can't
combine several .a into a new .a just by calling "ar".

brgds, H-P