Mathieu Lacage mathieu.lacage@gmail.com
Wed Feb 10 09:33:00 GMT 2010

it's bad taste to reply to self but...

On Wed, Feb 10, 2010 at 9:42 AM, Mathieu Lacage
<mathieu.lacage@gmail.com> wrote:

> 3) why is this scheme used instead of just using atexit+the normal
> constructor/destructor things on a per-binary basis ?

My brain must not be working right today: I suspect that the typical
usecase cxa_atexit is fixing is when you unmap from memory a shared
library which registered its destructors with atexit: you want to make
sure that when your application exits, it will not call the unmapped
destructors so, the best way to avoid this case is to remove the
destructors from the global atexit list when they are run during the
dlclose call.That answers my question 2 too:

> 2) I can't figure out how the code comes up with the third argument to
> __cxa_atexit and the first argument to __cxa_finalize. I expected some
> kind of per-binary global variable (say, __dsa_handle) for
> __cxa_finalize which would be set by the code calling __cxa_atexit but
> I can't see this symbol defined anywhere in my binaries. Of course, I
> can't see how __cxa_atexit comes up with this third argument. Is the
> __dso_handle really expected to be a the void *handle associated by
> the dynamic linker to this binary or is it merely expected to be a
> unique address specific to this binary ?

I see that the only requirement on __dso_handle is that it is a unique
value which uniquely identifies each binary during its lifetime.

I guess I only need to figure out 1) now...

Mathieu Lacage <mathieu.lacage@gmail.com>

More information about the Gcc-help mailing list