[uClibc] __cxa_atexit implementation

[Stephen Warren]

I have a program where constructors/destructors for various global 
objects interact with function-scoped static objects with 
constructors/destructors.

Without -fuse-cxa-atexit (application build time) or 
--enable-__cxa_atexit (toolchain build time), these interactions fail 
due to destructors getting run in an incorrect order.

Now, I assume such relationships are legal. Certainly with the standard 
Fedora Core 2 (and 3) gcc/glibc toolchains, everything works fine.

So, I have whipped up a patch for uClibc to implement __cxa_atexit. This 
allows use of the gcc option -fuse-cxa-atexit, which fixes my problem 
(by making all destructors for global objects be registered using 
__cxa_atexit - i.e. atexit - rather than being run in a static order 
after all atexit-style registrations have completed).

Note: I haven't actually even compiled this patch yet! I'm looking for 
feedback on things such as whether we should even add a Config.in option 
for it, and whether the code should really be cut/paste between 
atexit/on_exit/__cxa_atexit.

That said, I did put this code into my test app:

extern "C" int __cxa_atexit(void (*f)(void *), void *x, void *y)
{
   atexit((void (*)())f);
}

which is essentially what the patch does anyway (since the parameter is 
actually ignored by the functions gcc registers, at least for my test 
app). This solved the problem.

Also, note, that I have not implemented the (related???) function 
__cxa_finalize in this patch. When I build a shared-library with global 
objects having ctors/dtors, a weak reference is generated to 
__cxa_finalize by gcc, but even without an implementation, things seems 
to get run in the correct way. I get the impression from gcc sources 
that __cxa_finalize is only relevant for IA64/PARISC?

When I dlopen/dlclose a .so with a global object with ctors/dtors and 
everything built with -fuse-cxa-atexit and the above hacked __cxa_atexit 
in the .so, however, I do see a segfault on dlclose. I have not yet 
tracked down if this is related. I'll debug this more...

So, any comments on the patch (attached) (it's an "svn diff" from the 
top of the svn tree up-to-date as of today).

Thanks.

-- 
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren at wwwdotorg.org     http://www.wwwdotorg.org/pgp.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclibc-cxa-atexit.patch
Type: text/x-patch
Size: 4000 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20050814/d559e631/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20050814/d559e631/attachment.pgp