Re: Link with mixed IR/non-IR objects

[Alan Modra <amodra at gmail dot com>]

On Wed, Apr 27, 2011 at 07:06:44PM -0700, H.J. Lu wrote:
> On Wed, Apr 27, 2011 at 5:23 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Wed, Apr 27, 2011 at 07:38:23AM -0700, H.J. Lu wrote:
> >> They are different. SHT_GNU_OBJECT_ONLY section doesn't contain
> >> any IR. It encapsulates a relocatable object file without any IR bits.
> >
> > I think we first should ask whether GNU ld needs to support ld -r
> > with mixed IR and normal object files. ?I'm inclined to think that ld
> > should not do the segregation of object files and effectively perform
> > two linking operations with one output file stored inside the other.
> > Why can't we simply issue an error if someone tries to mix object
> > files like this?
> >
> 
> This is for usability. Many projects use "ld -r" on object files
> generated from C/C++ sources, assembly codes as well as
> from the third party vendors.  If "ld -r" doesn't work on mixed IR
> and non-IR object files, they have to change the build infrastructure
> if they want to use LTO.

IMNSHO it is a mistake to use ld -r as a means of packaging object
files.  Projects that do so ought to be encouraged to move away from
that practice, because ld -r doesn't just simply package object
files.  It can move code around, losing cache locality.  You can also
lose out on possible final link optimisations, eg. --gc-sections,
powerpc64 multi-toc.  Thin archives, or even @ response files, are a
better solution.

So I think we'd be doing the world a service by *not* supporting ld -r
with mixed objects.  I also don't like the added complexity in the
linker, and in the object file format.  Third party tools won't handle
these mixed object files.

-- 
Alan Modra
Australia Development Lab, IBM