Re: Problems with __cxa_demangle and the verbose terminate handler

[Benjamin Kosnik <bkoz at redhat dot com>]

>People have now noticed that libsupc++ and libstdc++ are no longer
>separable, since __cxa_demangle uses the new demangler, which itself
>uses std::string and std::vector.  That is a problem for embedded
>systems and other similar environments -- it makes G++ incompatible
>with the C++ ABI in those contexts in that the freestanding library no
>longer contains __cxa_demangle.

The freestanding libstdc++ not having a definition for __cxa_demangle is
not shockingly new behavior. It's the same incompatibility that existed
in 3.0, and 3.1. 

However, I agree, it would be a pity to step backwards and revert to
this old behavior in 3.4.

Thus, I think that __cxa_demangle has to be provided in libsupc++ as a
self-contained entity.

The bigger issue, to me at least, is that libsupc++ as it currently
exists, is not self-contained. Ie, the default terminate handler uses
__cxa_demangle, and that doesn't exist when just using libsupc++. This
is a critical bug and must be fixed so that libsupc++ is still useful.

This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10246

Three solutions to this problem are: 

1) keep the default terminate handler __verbose_terminate_handler, and
make people using libsupc++ set the new handler to std::abort 

2) keep the default terminate handler __verbose_terminate_handler, and
make __cxa_demangle self-contained.

3) switch the default terminate handler to std::abort

Perhaps there are other options, but #2 seems to be the only workable
solution for all the issues.

I don't know how to do #2 with the current demangler sources in
libstdc++. 

An additional issue is that the current demangler sources have a nicer
allocation interface than what's required by the C++ ABI. It would be
nice to keep this functionality as an extension, somehow.

>It is a bad idea for "__cxa_demangle" to throw exceptions, even if
>they are caught.  The reason is that "__cxa_demangle" is often called
>during some kind of severe error situation (such as the V3 verbose
>terminate handler).  One of the cases in which "std::terminate" is
>called is when the exception-handling machinery (such as
>"_Unwind_RaiseException") has failed.  The terminate handler should
>never call a function which might raise another exception as the
>internal unwinder state is not guaranteed to be consistent at this
>point.  Trying to raise another exception may just result in a
>recursive call to "std::terminate".  (I have a program which does
>exactly that; it eventually gets killed by the OS due to stack
>overflow via recursive calls to "std::terminate".)
>
>That argues, again, for using the C demangler.

I tend to think this is arguing for not throwing in terminate, actually.
I have run into these same issues with a per-thread terminate handler,
using "C".

However, that's incidental.

-benjamin