[Bug target/29487] Shared libstdc++ fails to link

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2007-02-05 00:15 -------
Subject: Re:  Shared libstdc++ fails to link

> I'm not sure what "EH data" is being described here.  Certainly, it
> makes no sense at all to emit EH unwind information for functions which
> are not part of the current object file; their unwind information will
> be emitted with those function.
> 
> What sort of data is being emitted?

Unwind data.  We're talking about functions compiled in the
current object.

On the HP-UX PA-RISC targets,  unwind data is placed in the data
subspace.  In principle, there's no problem with other EH data as
the HP linker can handle the relocations in "noload" subspaces.

In HP-UX 10, one-only was implemented using COMDAT subspaces.
When the linker sees the second or later occurence of a COMDAT
subspace with the same name as the first one, it nullifies these
subspaces and doesn't emit them in the final object.  However,
it turns out that that the linker can't handle relocations referring
to symbols in that are in a nullified subspace if these references
occur in a subspace that is loadable.  Didn't see this when
developing the DWARF2 unwind support for the 4.1 branch because
of the following issue.

There are numerous "one-only/weak" functions which don't bind locally
in libstdc++.  Previously, *ALL* these functions were determined to be
nothrow and no unwind data was emitted for them.  Now, unwind
data is being emitted because these functions don't bind locally.
This breaks the HP-UX 10 DWARF2 unwind implementation (obviously a
latent bug) because of the relocation issue mentioned above.  It also
increases the amount of DWARF2 unwind data emitted on all targets
using this exception mechanism and might have an impact on search
performance when unwinding.

It's my belief that DWARF2 unwind support present in GCC 4.1.0
and 4.1.1 for HP-UX 10 was usable in spite of the linker limitation.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487