Re: p2736.C Is dtor order guaranteed?

[hjl at lucon dot org (H.J. Lu)]

> 
> > I believe Linux has no such restriction. However, I'd like to revert
> > back to __DTOR_LIST__ if a shared library is loaded via dlopen.
> > Otherwise, we will get a core dump after dlclose when the program
> > exits. We can put a restriction on dlopened objects that they cannot
> > call atexit explicitly or implicitly in C or C++.
> 
> Since this dlopen thing seems to be a real concern, I think Jason's
> proposal of replacing atexit is the most reasonable. What if the C++
> runtime supported unregistering registered atexit functions. E.g.
> 
> void __cp_atexit(void (*)(), void *token);
> void __cp_doatexit(void *token);
> 
> extern "C" void atexit(void (*func)())
> {
>   __cp_atexit(func, 0);
> }
> 
> When constructing a static object, g++ emits a call to __cp_atexit,
> passing an per-object-file address to __cp_atexit. It also puts a DTOR

I assume you meant per-shared-object-file address. I don't know how
you can get it in g++ since it is determined by the linker and only
has a known value at the run time.

> in the object file calling __cp_doatexit with the same token.  So, if
> the object file is dlclosed before the program terminates, the C++
> runtime calls those atexit functions early. If the shared library is
> unloaded regularly, all atexit function are already called, and
> __cp_doatexit does nothing.
> 
> Regular atexit calls cannot be unregistered via this mechanism, as
> they don't have a token. Still, they do interleave with the global
> destructors as required.

I have some patches for egcs. They seem to work with my patched
glibc 2.0.7. The only restriction is you cannot have any atexit in a
dlopened shared library.

-- 
H.J. Lu (hjl@gnu.org)