Re: Cancelling atexit calls

[Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>]

> Perhaps you could tell us precisely what problem you are trying to solve.

There is a number of problems; some of them need to be solved in g++,
some might use C library support.

a) Destructors need to run in exact reverse order of construction;
   this holds even for destructors of static block-locals (for which
   the initialization order is not known at compile time).
b) Destructors in C++ need to interleave with atexit functions:
   If a call to atexit was made between the construction of two
   globals, that function needs to be called between the destructors.
c) When a shared library is unloaded using dlclose, the destructor
   code is not available when exit is called. Calling destructors
   inside dlclosed shared images at exit will lead to a crash.

To implement the first two requirements, destructors cannot go into
the .fini section, but must be registered with atexit.

To implement the third requirement, atexit must not be used as it will
crash when calling functions that don't exist anymore - unless it is
possible to cancel functions registered with atexit.

> As well as questioning the need for it, I am concerned about your new
> interface.  An ill-specified `token' address could be overloaded by
> different parties.  Make them take a `void **', the address of a location
> provided by the caller and initialized to 0 before the first call to
> `atexitc'; that is still fairly simple to use, and makes it easy for the
> implementation to just store there a pointer to the data structure it
> allocates.

This is a good idea.

> Also, `atexitc' is not a very good name.

This name tries to suggest 'at exit unless canceled'. Please propose
a different name.

> You cannot assume that a reference in a given shared object gets the
> value defined in that shared object (unless you linked it with
> -symbolic).

This is what I found. I still think it is unfortunate.

> You can use _GLOBAL_OFFSET_TABLE_.
> That symbol is magic and causes the assembler to produce a special reloc.
> (At least I think it still works this way.)

I'm a bit worried about portability here. If I have gcc generate
references to _GLOBAL_OFFSET_TABLE_, how do I know whether the
assembler does the right thing? It seems that the special-reloc thing
is performed only on i386.

Also, under your proposed interface, how could I get a reference
to a variable with exactly one copy per shared library?

Martin