__cxa_atexit question

Mark Mitchell mark@codesourcery.com
Tue May 16 18:22:00 GMT 2006


Benjamin Kosnik wrote:
>> I think it's reasonable to conditionally include a C++-aware atexit,
>> __cxa_atexit, and __cxa_finalize in libsupc++, which is then
>> incorporated into libstdc++.  On a system where these functions are not
>> in the C library, there's no other way to build a conforming C++
>> implementation. 
> 
> IMHO, checkbox only. Without interoperability with "C" not so useful.

I don't feel particularly strongly about this issue, but I do think some
checkboxes are important.  EDG's ability to pass every test in various
testsuites is certainly a nice marketing bullet, and people really do
make decisions based on that kind of data.

I do take your point about interoperation with C code.  However, on many
of these systems, if you link with a C++ runtime library that defines
atexit, then the C code in your application will call that version of
atexit as well.  I believe that other third-party C++ compilers often
provide atexit in their runtime libraries, for this reason.

>> Other C++ compilers provide their own runtime libraries
>> on such platforms, so as to conform to the C++ standard; why shouldn't
>> we do the same?
> 
> By not doing this, maybe HP can be convinced to do the sane thing?

It's not just HP-UX.  For example, Windows is another platform without
__cxa_atexit.  I'd be surprised if AIX had it.  I'd imagine there are
embedded RTOS that do not have it either.  I can well imagine that in
future we might want to be MSVC++ ABI compatible, even down to the level
of exception-handling, and that would necessitate additional support code.

I think the general issue here is that we are likely to run into
variants of the C++ ABI (e.g., ARM) and/or C runtime libraries without
some of the API functions we'd like (e.g., HP-UX).  I think we should be
flexible in dealing with those systems, being willing to include
appropriate support in libsupc++ so that G++ works as well as possible
on those systems, in the same way that libgcc contains different
routines on different systems to handle different software-floating
point conventions, etc.

I think the constraint should be that the additional code be added in a
way that is, as much as possible, out of the way of other systems.  But,
I think we should be willing to have whatever functions are required for
correct operation.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713



More information about the Libstdc++ mailing list