http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
--- Comment #11 from dave.anglin at bell dot net 2011-10-11 14:18:52 UTC --- On 10/11/2011 9:08 AM, jason at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 > > --- Comment #10 from Jason Merrill<jason at gcc dot gnu.org> 2011-10-11 > 13:08:19 UTC --- > Namespace-scope objects aren't the problem; we've always handled them fine. > The problem is with function-local statics, which aren't constructed until the > function is called, so we can't determine the order of construction at compile > time. We need to use atexit for them, and so for proper interleaving of > destructors we need to use atexit for namespace-scope objects as well, but > that > can cause trouble with dlclose, which is why we created __cxa_atexit. I understand this point. We don't use atexit on PA-RISC HP-UX for namespace-scope objects. On 32-bit HP-UX 11, we use a linker option to register initializer and finalizer routines for each executable and shared library. Thus, we don't have a problem with dlclose for namespace-scope objects. The problem is in using atexit for the function-local statics. Currently, collect2 builds a fixed list of destructors for namespace scope objects. Instead, what I'm suggesting is building the list of destructors dynamically for executables and shared libraries. The namespace-scope and function-local statics would be merged into one list that would be processed by the finalizer for the object. For systems that need to use atexit, I'm not sure whether this is worth the effort. The dlclose problem would remain. I'm not sure that destructor order would be deterministic in a multithreaded application. Dave
