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


On Thu, 13 Aug 1998, Joe Buck wrote:

> > Why can't we simply make the
> > compiler replace the user-level atexit() calls with our own atexit() with
> > no limits? This way we would conform to the standard, right?
> Yes, on platforms where we control the C library, or where atexit
> is not crippled, that is the solution: just use atexit().

I'm sorry, I haven't made myself clear enough.

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 solution:

1. is portable (it doesn't matter how the real atexit() is implemented).

2. allows for any number of atexit()/static destructors, no matter how
crippled the standard atexit() is, since only 1 (one) cleanup routine
is registered to the standard atexit().

> And
> as someone pointed out, with shared libraries linked against libc it
> might be difficult to force the replacement function to be called.

I know little of how shared libraries work, so I can't tell if this
comment aplies or not. The way I see it, my idea, if implemented, can't
make the matters worse.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets GCC maintainer   UNIX system administrator       |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /



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