[PING][PATCH][RFC] vterminate use of malloc-less demangler

[Simon Baldwin]

Thanks for the notes.  Inlined responses below...

Benjamin Kosnik wrote:

>
>> Please review http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02435.html
>
>
> Questions:
>
> 1) do you have a testcase? Seems as if this is the case. Can you 
> please include it?


Testing this work is, unfortunately, rather tricky.  I do have a simple 
test case, appended below, that allows me to confirm manually that 
__verbose_terminate_handler is operating without heap use.

This test, however, is hard to fit into any test framework.  First, it 
aborts whether or not it's successful; that's the nature of changing 
termination code.  Second, it relies on MALLOC_CHECK_, making it Linux 
only and not portable.  And third, it relies on carnal knowledge of 
libc's heap organization in order to "lightly" corrupt the heap without 
overdoing it.

Some of these restrictions might be avoidable.  For example, interposing 
malloc, realloc, free, and calloc catches calls to heap functions in the 
same way as MALLOC_CHECK_, so could make the test slightly more 
portable.  This still isn't fully portable across all platforms, though, 
and may require platform-specific link options even where practical.  
Likewise, the abort() can be caught with a SIGABRT handler, but again is 
not portable.  I experimented with a test based on these ideas, but it's 
probably too complex to be reliable.

There seems to be no identifiable current vterminate.cc test I can 
extend for this patch.  If you have other ideas for how to add a 
suitable test to the libstdc++ test suite, please let me know.

> 2) Are you planning on making this new function available to other 
> users besides the verbose terminate handler? If so, the declaration 
> should go below cxa_demangle in cxxabi.h and the function should be 
> exported. If not, the declaration should be removed.


The __gcclibcxx_demangle_callback() function is intended as a private 
contract between glibc and libstdc++.  There's no plan to use it 
elsewhere.  Callback-based demangling for general use is provided by 
cplus_demangle_v3_callback(), supplied by libiberty's include/demangle.h 
as an extension to the existing cplus_demangle_v3().  Moving the 
declaration of __gcclibcxx_demangle_callback() to cxxabi.h is also 
slightly misleading, as the function isn't actually part of the defined ABI.

The current declaration can't be removed if not placed in cxxabi.h -- 
this would prevent the vterminate.cc from compiling.

> 3) Do you see any other functions in libsupc++ that start with 
> __gcclibcxx_? If not, what do the rest of the runtime functions start 
> with, and what do you think about using that prefix?


There don't appear to be any other functions that are private contracts 
between glibc and libstdc++, so this name seems reasonable.  In 
particular, it's not part of the C++ ABI, so naming it __cxa_... was 
deemed unacceptable.  (In practice, it's actually a variant of 
__cxa_demangle(), but has to have a different name as the specification 
of __cxa_demangle() doesn't permit malloc-less operation).

The function is already in glibc, named thus, as part of revision 121305 
-- this patch merely activates it.  The name was suggested as a way to 
indicate glibc functions that are specifically intended for use by C++, 
but not part of any defined ABI.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: terminate_test.cc
Type: text/x-c++src
Size: 3176 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20070213/9c315c3c/attachment.bin>