Problems with __cxa_demangle and the verbose terminate handler

[Mark Mitchell]

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

Yes.

The C++ ABI requires that __cxa_demangle be provided by the language 
support library.  For us, that's libsupc++.  In order for us to be 
compliant on a freestanding system, libsupc++ must contain __cxa_demangle.

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

Yes.

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

Me neither.  But, it will be easy to do if we switch to the version in 
libiberty.

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

There's no reason that the libiberty demangler can't get extra 
parameters corresponding to the functions that are provided by the 
allocator interface.  For example, it could take additional parameters:

   void* allocator,
   void* (*alloc)(void *, size_t),
   void  (*release)(void *, void *)

Then, __cxa_demangle would pass in stubs that call malloc/free, and 
whizbang C++ code could pass in allocator functions.  This is not as 
tidy as the C++ interface, but, hey, so it goes.

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

 From the point of view of this issue, it would be fine to use a 
demangler written in C++, so long as it didn't use any standard library 
components that might throw exceptions.

With that constraint, however, coupled with the freestanding constraint, 
there's not much benefit in using C++ at all -- you might as well just 
use plain C, and gain the benefits of sharing the code with lots of 
other GNU tools.

So, and here I think we are perhaps in agreement now, we should switch 
the V3 library to use the implementation of the demangler in libiberty.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com