Re: Using __cxa_atexit on Solaris

[Ian Lance Taylor <iant at google dot com>]

rvyas <rishabh.a.vyas@gmail.com> writes:

>> As far as I know, that should work.  However, if your program uses
>> dlopen, then gcc needs the __cxa_atexit function to destroy globals in
>> the right order.
>
> Thanks Ian. How do I figure out if my program uses dlopen and is there a way
> around that?

I'm not sure how to answer the question of whether your program uses
dlopen.  I assume that the obvious answer of grepping the source code
doesn't work for some reason.  If you have a dynamically linked
executable you could run readelf -r and look for dlopen.


> Also, I have attached a simple piece of code which replicates the problem.
> While built/run on solaris/gcc it gives the following output:
>
> Function static 1 constructor called
> Function static 2 constructor called
> Global static 1 constructor called
> Global static 2 constructor called
> Function static 2 destructor called
> Function static 1 destructor called
> Global static 2 destructor called
> Global static 1 destructor called
>
> The function statics are both created and destroyed before global statics
> which is incorrect.
>
>
> http://old.nabble.com/file/p30238350/gcc-statics.cpp gcc-statics.cpp 

OK, in that case the dlopen thing is a red herring.  Sorry about that.
I was able to recreate the problem using -fno-use-cxa-atexit.  The
problem is that without __cxa_atexit, there are two different mechanisms
for destructors.  Static destructors are run via atexit.  Global
destructors are run via .ctors/.dtors.  This is so that dlclose will
correctly destroy global variables, acknowledging that the program gets
the wrong results for function statics.  Your code shows that the
program gets the wrong results for function statics even if dlclose is
not called.

In the absence of __cxa_atexit, it seems like the choices are: 1) get
correct ordering for destruction of globals and function statics at the
cost of not destroying globals when dlclose is called; 2) destroy
globals when dlclose is called at the cost of incorrect ordering for
destruction of globals and function statics.

I don't see any obvious fix for this issue that does not require the
cooperation of the system library, because it is the system library
which handles dlclose and exit.

Ian