This is the mail archive of the
mailing list for the GCC project.
Re: Cancelling atexit calls
- To: roland at frob dot com
- Subject: Re: Cancelling atexit calls
- From: Martin von Loewis <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Sun, 6 Sep 1998 23:58:06 +0200
- CC: libc-alpha at gnu dot org, egcs-patches at cygnus dot com
- References: <199809062054.QAA01799@baalperazim.frob.com>
> I see. Are these behaviors specified by the C++ standard?
Of course they are. This is all explained in 3.6.3, I'll hilite the
* These objects are destroyed in the reverse order of the completion
* of their constructor or of the completion of their dynamic
* initialization. ...
* If a function is registered with atexit (see <cstdlib>, 18.3) then
* following the call to exit, any objects with static storage
* duration initialized prior to the registration of that function
* shall not be destroyed until the registered function is called from
* the termination process and has completed. For an object with
* static storage duration constructed after a function is registered
* with atexit, then following the call to exit, the registered
* function is not called until the execution of the object's
* destructor has completed. If atexit is called during the
* construction of an object, the complete object to which it belongs
* shall be destroyed before the registered function is called.
> Any given text address in the shared library will suffice as unique
> pointer while the library is loaded.
With that approach, the compiler can only use symbols in the same
object file. Each object file that goes into the shared library then
needs cancellation for atexit. So I need to build a vector, which
seems wasteful, since a single word would be sufficient.
Since the interface proposed does allow for this optimization, we can
implement the proposed interface know, and optimize later.
I still could use comments/guidance from g++ people, with regard to
I'll provide an update to it using the new atexit interface next week.