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

[Alan Modra <amodra at gmail dot com>]

On Tue, May 08, 2012 at 01:03:24PM -0700, Andi Kleen wrote:
> >- 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.
> 
> Is that a real problem for the kernel?

Powerpc64 needs to build parts of the kernel with -mminimal-toc just
to work around this ld -r issue.  That means less efficient code.

> As far as I can tell the only real problem is the LTO issue and HJ solved
> that.

The real problem is that you are using the wrong tool for the job.

The issues I raised are just supporting evidence for why ld -r is the
wrong tool.  Of course you can ignore the issues or work around them,
but continuing to use the wrong tool will likely run into more
issues in the future.

> If HJs patchkit is not merged I just have to advise people to use
> his toolchain
> for LTO kernel builds instead. That would be unfortunate.

Does it concern me that you will recommend HJ's binutils?  Not at all!

Some years ago one of the gcc developers (no longer active) came up to
a group of binutils developers at the gcc conference, and asked
"Aren't you concerned about HJ's fork of binutils, and shouldn't you
do something to stop his releases?" or words to that effect.  Both
Nick and I replied "No, we're quite happy with the situation.  It
isn't really a fork.  HJ is providing a service that users want in
frequent releases, and the binutils project benefits by having more
people testing mainline binutils for us."  I still think that way.

-- 
Alan Modra
Australia Development Lab, IBM