it's bad taste to reply to self but... On Wed, Feb 10, 2010 at 9:42 AM, Mathieu Lacage <mathieu.lacage@xxxxxxxxx> 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 -- Mathieu Lacage <mathieu.lacage@xxxxxxxxx>
