This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Problems with __cxa_demangle and the verbose terminate handler
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, phil at codesourcery dot com, zack at codesourcery dot com
- Date: Mon, 23 Feb 2004 15:36:33 -0800
- Subject: Re: Problems with __cxa_demangle and the verbose terminate handler
- Organization: CodeSourcery, LLC
- References: <200402212107.i1LL7epU019387@sirius.codesourcery.com> <20040223170409.50fd0b94.bkoz@redhat.com>
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