This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: global {con,de}structors, atexit & friends
> I don't think that giving any guarantee that the constructors in
> different objects (main program, shared objects) are run in any
> specific order. I consider these objects as individual programs which
> "accidently" share the same address space.
Well, the standard is quite explicit what a program is (**), and these
different executable files are certainly not separate programs.
> One could try to solve this problem as well but a) the standard does
> not mention this case
While the standard puts no requirement on the order of initialization
of objects in different translation units ([basic.start.init]), it
clearly says what the order of destruction is ([basic.start.term]):
>> ... These objects are destroyed in the reverse order of the
>> completion of their constructor or of the completion of their
>> dynamic initialization.
> b) solving it would again lead to a avery slow solution.
How so? At the moment, the ELF interpreter loops over the shared
objects and invokes the .fini code, which in turn loops over tables
and calls destructors. Using lists instead of vectors can't add that
much overhead.
But then, your proposal also supports conforming atexit ordering as an
option, and that option would also guarantee correct reverse
destruction across shared objects. So in the non-conforming option, I
agree that we don't have to be that ambitious; getting the order right
within a shared library is probably sufficient - we just have to
document it clearly.
Regards,
Martin
** [lex.phases]/9, [basic.start.main]: A program shall contain a
global function called main