This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Link with mixed IR/non-IR objects
- From: Alan Modra <amodra at gmail dot com>
- To: generic-abi at googlegroups dot com
- Cc: binutils at sourceware dot org
- Date: Tue, 3 May 2011 12:27:51 +0930
- Subject: Re: Link with mixed IR/non-IR objects
- References: <b7c06571-1614-49af-ab54-2061c2bfbf91@l2g2000prg.googlegroups.com> <20110427142909.GA1619@x4.trippels.de> <BANLkTikYXO-UB4TL_MzYvBR29s2g-2Q7-Q@mail.gmail.com> <20110428002358.GE19947@bubble.grove.modra.org> <BANLkTi=SToofwMGv=hRHLACHfMWWOJxiuQ@mail.gmail.com> <20110429014411.GQ19947@bubble.grove.modra.org> <BANLkTimHnDwpc5LvYK-DVEfO9X8SzMEgqA@mail.gmail.com>
On Fri, Apr 29, 2011 at 03:38:50PM -0700, Cary Coutant wrote:
> 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.
Yes, and all of this except for the extension to the archive format
could be done in a wrapper (perhaps even the gcc driver).
> 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.
Won't work without using separate symbol tables or an extension to
mark symbols as IR-only. The linker should detect when a symbol is
only defined in IR files and report an error if the symbol is then
referenced in a relocation.
--
Alan Modra
Australia Development Lab, IBM