This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: static constructors/destructors and atexit



> What I'm proposing is that the compiler replaces user-level calls to
> atexit() with, say, __nl_atexit() (No Limits atexit), and that it uses
> __nl_atexit() for static destructors, too. __nl_atexit() is defined in
> libgcc.a and it simply appends the function address to an internal list
> and, on the first invocation, calls the real atexit() with its own cleanup
> routine as parameter, a routine that calls all the functions from the
> internal list.

This proposal will work according to the standard if all code is compiled
by gcc/g++.  The issues come about when we mix with code from other compilers.

I think that we can assume that this other code is all C (you can't
mix different C++ compilers), so it may have atexit calls but won't
have any destructor calls.

Since this other code will be calling the real atexit(), then the atexit()
calls for the whole program may not be in the right order.

The reason I brought up shared libraries was because I thought you
were proposing to write a new atexit() to use instead of the official
one, calling it atexit rather than __nl_atexit.  This one would have
to be OS-specific, since it would replace the system atexit(), instead
of using it, but it would have no problems with the linked code, as it
would get the new atexit() also, unless pre-linked with the real atexit().

Your approach has problems with *any* precompiled libraries (other
than those built with a gcc that uses __nl_atexit()), in that the
atexit calls won't happen in the right order: once the first registration
from gcc code happens, any registration by atexit from non-gcc code will
have its cleanup function delayed until after all the gcc cleanup
functions.

For most users, the problem doesn't matter, at most atexit handlers
are going to be independent of each other.

So, as I said, the only way to achieve perfect standards conformance
is to call atexit.  Since, on Solaris, this causes an unacceptably
low capacity bound, your proposal would make sense there even though
it is technically non-conforming, though for the pedantic we could
give them direct atexit calls.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]