This is the mail archive of the
mailing list for the glibc project.
Re: Cancelling atexit calls
- To: Martin von Loewis <email@example.com>
- Subject: Re: Cancelling atexit calls
- From: Roland McGrath <firstname.lastname@example.org>
- Date: Sun, 6 Sep 1998 07:25:59 -0400
- Cc: email@example.com, firstname.lastname@example.org
- Emacs: it's all fun and games, until somebody tries to edit a file.
Perhaps you could tell us precisely what problem you are trying to solve.
dlclose calls the DT_FINI function of the shared object, which in practice
is the _fini symbol for the start of the .fini section when the shared
object is linked. Destructors are normally called from the .fini code,
which is pieced together by the linker from the .fini sections of all the
modules linked together to create the shared library.
The dynamic linker's finalization function, which is registered with atexit
by the startup code (crt1.o), does the same thing for all shared objects
that are loaded at exit time.
I am not aware of any failure of this system to meet the needs of C++
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
Also, `atexitc' is not a very good name.
As to the address of `_end', it is like all global symbols referenced in
dynamically-loaded objects (non-DT_SYMBOLIC ones): the name is searched for
first in the program itself, and then in the shared objects in the
specified order. You cannot assume that a reference in a given shared
object gets the value defined in that shared object (unless you linked it