Re: p2736.C Is dtor order guaranteed?

[Martin von Loewis <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> 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
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.

Martin