p2736.C Is dtor order guaranteed?

[Jason Merrill]

>>>>> H J Lu <hjl@ocean.lucon.org> writes:

>> So it is broken.  init5.C will test for this kind of misbehavior too,
>> but egcs can't currently handle destruction of local static variables
>> interspersed with global variables.

> The current implementation is wrong. We have to put the destructors
> for local static variables onto __DTOR_LIST__. Otherwise, we will also
> run into problems with dlopen/dlclose.

The reason for doing it with atexit is that destruction of statics (local
or not) must be interleaved with calling functions registered with atexit:

   The function exit() has additional behavior in this International
   Standard:

     First, objects with static storage duration are destroyed and
     functions registered by calling atexit are called. Objects with static
     storage duration are destroyed in the reverse order of the completion
     of their constructor. (Automatic objects are not destroyed as a result
     of calling exit().)*

          [Footnote: Objects with automatic storage duration are all
          destroyed in a program whose function main() contains no
          automatic objects and executes the call to exit(). Control can be
          transferred directly to such a main() by throwing an exception
          that is caught in main(). --- end foonote]

     Functions registered with atexit are called in the reverse order of
     their registration.* 

          [Footnote: A function is called for every time it is
          registered. --- end foonote]

     A function registered with atexit before an object obj1 of static
     storage duration is initialized will not be called until obj1's
     destruction has completed. A function registered with atexit after an
     object obj2 of static storage duration is initialized will be called
     before obj2's destruction starts.

but your concern is, of course, valid.  The other concern, that this
doesn't handle interleaving of local and file-scope statics, is also
valid.  The problem is finding a way to fix all of these problems that
isn't unreasonably expensive.

> One way to fix all these is

> 1. egcs reserves a slot on __DTOR_LIST__ for the destructor of the
> local static variable. We can mark it as -1 so that
> __do_global_dtors_aux won't run it.
> 2. Put an auxiliary constructor of the local static variable on
> _CTOR_LIST__ to record some information for the real constructor.
> 3. The real constructor of the local static variable will put the
> destructor in the reserved slot on __DTOR_LIST__ and rearrange
> the order of __DTOR_LIST__ if necessary.

But that doesn't handle the atexit problem.  The idea of rearranging
__DTOR_LIST__ is also a bit dodgy.

Jason