__cxa_finalize and `on_exit'

[Jim Dehnert]

> From: Mark Mitchell <mark at codesourcery.com>
> Date: Thu, 16 Dec 1999 15:51:16 -0800
> 
> Why does the ABI says that __cxa_finalize should be called with a NULL
> parameter from the main program in the .fini section?  Why not just
> let normal atexit processing take place when exit is called?

There's a circularity problem, due to the need to register "normal"
atexit calls to get them in the proper sequence.  Rather than do a
traditional atexit registration, in C++ atexit must register the calls
in the same sequence used for destructors.  So you can't just register
__cxa_finalize with atexit, because it would end up invoking itself.


> From: Mark Mitchell <mark at codesourcery.com>
> Date: Thu, 16 Dec 1999 16:03:06 -0800
> 
> The GNU C library supports the BSD/SunOS-ish `on_exit' as well as
> `atexit'.  A function registered with on_exit is just like one
> registered with atexit, except that it (like functions registered with
> __cxa_atexit) takes a parameter, and that parameter is registered at
> on_exit time.

__cxa_atexit registers a parameter with the function to be called,
so this aspect of on_exit could be supported already by the proposal,
as you observe.

> In addition, the function registered with on_exit is passed the
> exit-status when exit is called.
> 
> But, __cxa_finalize doesn't know the exit-status, even when called
> with NULL to indicate that the main program is exiting, so it can't
> call the on_exit functions correctly.
> 
> I suggest that we mandate that __cxa_finalize is always called with a
> non-NULL parameter, or that it immediately return if passed a NULL
> parameter.
> 
> Let's just let exit do it's normal thing (which will include calling
> __cxa_atexit-registered functions), and use __cxa_finalize only for
> DSOs.

It's not clear how exit "doing its normal thing" solves the circularity
problem above.  The conclusion we came to was that the normal thing
today means that noone is conforming to the standard, and that's one of
our objectives (for normal exits, as opposed to dynamic DSO unloading).

We can certainly deal with the exit status by passing that to
__cxa_finalize when the current DSO handle is NULL, if that's desirable
(e.g. to integrate Sun's on_exit into the scheme).  That would involve
changing to:

	void __cxa_finalize ( void *dso_handle, int exit_status );

and calling the registered functions *f with

	void (*f) ( void *registered_p, int exit_status );

We would have to identify what exit_status to use on early DSO unload,
i.e. when dso_handle is non-NULL -- it could be zero, or undefined, or
some selected value.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272