This is the mail archive of the
mailing list for the binutils project.
Re: Link with mixed IR/non-IR objects
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 <email@example.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
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.
Australia Development Lab, IBM