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

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

------- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2006-12-04 01:29 -------
Subject: Re:  Shared libstdc++ fails to link

> > > This problem was introduced by this change:
> > That makes less sense really, because this just changes how to deal with
> > TREE_NOTHROW.  This sounds like a latent bug really.
> 
> The change does affect the EH table (diff attached).  Hacking the
> assembler output for stdexcept, I find that it's the following
> reference that causes the error:
> 
>         .word   L$FB0940

The TREE_NOTHROW change exposes a problem in HP ld that only can be fixed
by HP and that's not going to happen.  The TREE_NOTHROW change has been
applied to 4.1, so we have a regression.  However, it probably would be
possible to trigger this problem even without the TREE_NOTHROW change
(e.g., setting flag_non_call_exceptions).  So, I think the only fix
is to revert DWARF2 EH support on this target on 4.1 and later ;)

I've debugged HP ld sufficiently to determine the nature of the problem.
Weak symbol support is implemented on this target using "COMDAT" subspaces.
When duplicates occur in a link, the HP linker nullifies symbol references
to the second and latter occurences of symbols in the "COMDAT" subspace.
It does this by changing the symbol type to ST_NULL.  As a result, the
references to omitted subspaces change from ST_DATA to ST_NULL.  This
triggers the DATA_ONE_SYM_FOR_PLAB error from HP ld when we hit a reference
in the DWARF2 EH table to an omitted subspace.

The message is actually somewhat misleading as we nominally started with
a ST_DATA symbol and not a ST_CODE code symbol.  Well, actually the symbol
is a code symbol but the default is to treat code labels as data symbols!

I tried changing the absolute reference to a plabel reference but this
results in another problem.

Attached is a simplified bit of assembler output from stdexcept.cc
and a small hack to HP ld which might work around the problem.  To
trigger the problem, the assembled output from pr29487.s needs to included
twice in a shared link.

Dave


------- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2006-12-04 01:29 -------
Created an attachment (id=12737)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12737&action=view)


------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2006-12-04 01:29 -------
Created an attachment (id=12738)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12738&action=view)


-- 


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