#291 cxa_atexit support in dllcrt

Patch_under_review
closed-rejected
Danny Smith
2006-07-19
2006-04-10
Alexander Dubov
No

When working on some program I'd run into situation
where g++ insists on cxa_atexit code generation (that
is, I had to use a specific build of g++). First I
thought to patch up my code only, but then my program
would crash before even reaching dllmain. So I
patched dllcrt1.c and added cxa.c file (borrowed from
stlport project here on SF, with minor modifications;
it is essentially identical to all other cxa_atexit
implementations) to the libmingw32.

I made no modifications to crt1.c as I'm not building
any executables with my dll's (its a JNI project), so
I can't test it.

P.S. MSDN says it's ok to initialize mutex objects in
dllmain.

Discussion

  • patch against mingw-runtime-3.9

     
    Attachments
  • Danny Smith
    Danny Smith
    2006-04-18

    Logged In: YES
    user_id=11494

    Why is cxa_atexit registration necessay for win32 DLL's?
    Each DLL has its own private atexit table which gets run
    when the DLL unloads? Couldn't cxa_ateit just be a
    wrapper for dllonexit?

    Can you provide a testcase where cxa_atexit is necessary
    or beneficial?

    Danny

     
  • Danny Smith
    Danny Smith
    2006-04-18

    Logged In: YES
    user_id=11494

    Why is cxa_atexit registration necessay for win32 DLL's?
    Each DLL has its own private atexit table which gets run
    when the DLL unloads? Couldn't cxa_ateit just be a
    wrapper for dllonexit?

    Can you provide a testcase where cxa_atexit is necessary
    or beneficial?

    Danny

     
  • Logged In: YES
    user_id=1071506

    I don't really know all the technicalities, but I understand
    following to be correct:
    When compiled with "--enable-__cxa_atexit" g++ always emits
    additional code for the dso (dll). On construction of any
    global/static object, it's destructor is added to the
    exit_function_list, so the destruction of this object will
    happen in the correct (and thread safe) order on dso
    unloading. This happens somewhere in the do_global_ctors /
    dtors stage.

    Now, I was using a third party library that specifically
    demanded cxa_atexit, so I could not simply recompile the g++
    to use older behavior (e.g. omit the aforementioned build
    option).

    In general, cxa_atexit is considered the "right way" to do
    things:
    http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor

    (it seems that for code doing dso loading/unloading the
    destructor behavior was not strictly correct with old style
    destruction).

     
  • Danny Smith
    Danny Smith
    2006-05-22

     
    Attachments
  • Danny Smith
    Danny Smith
    2006-05-22

    Logged In: YES
    user_id=11494

    Adding attached to libgcc.a (via LIB2FUNCS_EXTRA
    mechanism) also allows an --enable-__cxa_atexit build.

    In the long run, I believe, a proper C runtime
    implementation such as your submission is prefereable, but
    to do that we need to integrate standard atexit with a -
    fnew-abi __cxa_atexit.

    As far as a simple testcase, g++.old-deja/other/init5.C
    shows why __cxa_atexit is needed even in absence of dll
    loads.

    Can you provide more details on the origin (and licensing
    restrictions) on your source submission?

    Danny

     
  • Danny Smith
    Danny Smith
    2006-05-22

    • labels: --> MinGW runtime
    • assigned_to: nobody --> dannysmith
     
  • Danny Smith
    Danny Smith
    2006-07-19

    • milestone: --> Patch_under_review
    • status: open --> closed-rejected
     
  • Danny Smith
    Danny Smith
    2006-07-19

    Logged In: YES
    user_id=11494

    I don't think this is the right way, since a proper
    implementation would mean replacing msvcrt.dll's atexit
    with a mingw one that is integrated into __cxa_atexit.

    Although that should work, Mark Mitchell (the GCC release
    manager) has persuaded me that patching the C++ frontend
    to use MSVCRT's atexit would be preferable. I have a
    patch to do such which I will submit when GCC branches.

    Danny