Re: Link with mixed IR/non-IR objects

[Cary Coutant <ccoutant at google dot com>]

> 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.

I'm also not much in favor of using ld -r as a means for packaging
files, but it still has other uses. Those other uses typically involve
combining modules and hiding symbols, types of activities that might
also go well with actually doing localized LTO during the link, and ld
-r ought to work fine in that scenario.

Nonetheless, I think it can be useful to run ld -r while deferring LTO
to the final link, but my problem with this proposal is the whole
concept of nesting an object file inside a section of another object
file. We already have at least two mechanisms for this kind of
encapsulation: archive libraries on the one hand, and section groups
on the other. I think either one of those could be used to solve the
problem without inventing a third kind of encapsulation.

I suggested earlier a scheme where the linker could generate an
archive of objects, one member being the result of an ld -r on all the
non-IR inputs, the other(s) being the IR inputs. A trivial extension
to the archive format could designate to the linker that all members
must be loaded.

For something more like the object-inside-a-section solution, I don't
see why section groups couldn't be made to work. ELF has a group type
that currently defines only the one type of group (COMDAT). You could
define a new type of group that would contain the mixed compiled-code
and IR sections from a mixed-IR input file, and the result of an ld -r
over a mixed input would contain regular sections representing the
combination of the non-IR inputs, and a group of sections for each IR
input.

Either one of these alternatives sounds better to me than embedding a
whole object in a section inside another object file.

-cary