Re: ld 2.16.1: Ordered & unordered sections error on IA64

[James E Wilson]

On Thu, 2005-12-22 at 10:25, John S. Worley wrote:
> ld: .data has both ordered and unordered sections
> ld: find link failed: Bad value

You might try using FSF binutils mainline, to see if perhaps the problem
is already fixed.

Current binutils mainline will emit a more helpful message, which gives
section names and file names.

It is possible that binutils-2.14 had a latent bug, and was silently
creating bad executables.  Since only the unwind info was affected,
there could only be a problem if a signal or exception was thrown, and
you tried to unwind to recover.  This is presumably a rare case, and if
it failed, you might dismiss it as a problem with error recovery code.

You should check that your linker script is OK.  Trying to put
IA_64.unwind sections in .data sounds a bit unusual.

IA_64.unwind sections contain unwind info for text sections.  Because of
how they work, the unwind info sections must be appended in the same
order as the corresponding text sections.  SHF_LINK_ORDER is used to
implement this feature.  All IA64.unwind sections must have
SHF_LINK_ORDER set, and the sh_link/sh_info fields pointing at the
corresponding text section.  See the Itanium ABI and Itanium software
conventions and runtime architecture guide for more info.

The error you are getting implies that some IA_64.unwind sections have
SHF_LINK_ORDER set, and some don't.

There have been a few bugs in this area which have been fixed.  These
may or may not be related to the problem you are seeing.
    http://sourceware.org/bugzilla/show_bug.cgi?id=1321
    http://sourceware.org/bugzilla/show_bug.cgi?id=1991
These are both problems with strip/objcopy not getting the
SHF_LINK_ORDER right in the output.  Are you trying to link something
that has gone through strip and/or objcopy?  This could cause the
problem you are seeing, if strip/objcopy produced corrupted output.

We probably can't do much more without a testcase that we can use to
reproduce the problem.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com