This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Link with mixed IR/non-IR objects


On Mon, May 02, 2011 at 10:51:36PM -0700, Cary Coutant wrote:
> >> 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.
> 
> No extension is necessary -- if the symbol is defined in an IR input,
> the st_shndx field will point to a member of an IR section group.

That's true for most symbols but not true for common or absolute
symbols, or any symbols using the OS or PROC specific sections.  If
you don't treat SHN_COMMON IR-only symbols as special, the linker will
needlessly allocate space for them.

And, yes, I wasn't correct to say that the linker should report errors
on relocations against IR-only symbols.  As you said, the linker
should treat these as undefined.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]