> From: Ranjit Mathew > Sent: Sunday, June 25, 2006 1:28 PM > Danny Smith wrote: > > Adding a real __cxa_atexit to mingw runtime is of course also > > possible, but I thought I'd attempt the easy options first. > > When you say "runtime", do you mean libstdc++ or something like > libmingwex.a in "mingw-runtime"? If you mean the former, you can add > this in for GCC 4.2 and work on a real > __cxa_atexit() for GCC 4.3, if you want. >
A real __cxa_atexit solution needs to be integrated into the "mingw-runtime". The initialization and finalization of the at-exit tables needs to be handled by mainCRTStartup/DllMainCRTStartup and the C runtime functions _onexit, atexit and possibly dllonexit need to rewritten as wrappers around cxa_atexit. As it turns out, that is fairly simple: eg., the version of __cxa_atexit and friends that is in the STLPort library translate to mingw quite easily with a few minor tweaks to accomodate the win32 API. And integrating atexit/_onexit into cxa_atexit is facilitated by the fact that the msvcrt versions of these functions are exported only as "_imp__" prefixed indirect references, so that we can avoid getting mixed up with MS version of these functions. I have tested all that with a basic single-threaded implementation and no problems. But that won't happen before 4.2 is released. I don't know how difficult it will be to convince other mingw developers that this idea is a good thing: replace an ISO standard-conformant and perfectly adequate atexit function already supplied by OS vendor with a new version, perhaps with some licensing strings attached. I expect the fake cxa_atexit hack I illustrated earlier would meet less resistance, and that is why I considered it the easier option. Me? The __cxa_atexit behaviour is documented. AFAICT, the msvcrt-specific behaviour of the atexit and dllonexit functions is not, and was 'discovered' by a lot of trial and error. So, today, I'd prefer to implement a real __cxa_atexit and point users to the ABI specs. Thanks for replying to this thread, Ranjit. We'll see if any other mingw developers read this list. Danny > Thanks, > Ranjit. > >
