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

[mark at codesourcery dot com]

------- Comment #17 from mark at codesourcery dot com  2007-02-05 03:06 -------
Subject: Re:  Shared libstdc++ fails to link

dave at hiauly1 dot hia dot nrc dot ca wrote:

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

OK.

I'm not sure it matters, but if these functions don't throw exceptions,
I don't understand why we're not marking them TREE_NOTHROW.  I suspect
there's something that I'm just not following.

The fact that linker semantics allow you to replace a function at the
object level do not make it valid at the language level.

So, for example, I would expect:

  void f () throw () {}

and:

  void g() {}

to both be TREE_NOTHROW, independent of linkage, weakness, etc.
Certainly, not marking such functions as TREE_NOTHROW will inhibit
optimization of their callers, which seems bad.

Why aren't the functions being marked TREE_NOTHROW?

> 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.

I understand that this is a latent bug in the HP-UX linker.

To be honest, I'm less concerned about HP-UX 10.10 per se than about the
possible bloat on other targets.  (HP-UX 10 is not a primary or
secondary target.)  At the same time, I certainly don't want to
gratuitously break any target.

Assuming that the changes in TREE_NOTHROW and emission of exception
information make sense, what solution would you implement for HP-UX 10?
 Use SJLJ exception handling?

Thanks,


-- 


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