http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #50 from Cary Coutant <ccoutant at gcc dot gnu.org> 2010-12-13 20:24:43 UTC --- Sorry for jumping in so late here, but it sounds like the conclusions here match my recollections: - We added .init_array/.fini_array in order to blend the SVR4 version of .init, which contained actual code, with the HP-UX version, which contained function pointers and used a DT_INIT_SZ entry in the dynamic array rather than prologue and epilogue pieces contributed from crt*.o files. The HP-UX version was seen as an improvement, but it wasn't compatible, so we renamed the sections and the dynamic table entries so that the two versions could live side-by-side and implementations could transition slowly from one to the other. - On HP-UX, we used .init/.init_array for static constructors, and they registered the corresponding static destructors on a special atexit list, rather than adding destructors to .fini_array, so that we could handle destructors on dlclose() events properly (subject to your interpretation of "properly" in that context) [http://www.codesourcery.com/public/cxx-abi/abi.html#dso-dtor]. - Because .init was always executed from beginning to end (as code, there really wasn't much alternative), so was .init_array. - The gABI guaranteed that the init sections from a DT_NEEDED entry would execute before those from the library containing that DT_NEEDED entry (reverse topological order). - Constructor execution order within a translation unit was guaranteed, but there was no specified ordering between translation units within an executable or shared library (although in practice it was link order). Those of us in the discussions were mostly pro-shared library, so we weren't too worried about running initializers backwards with respect to link order. The C++ ABI group specified a way to record the constructor priorities, different from the .ctors.nnnnn method used by gcc [http://www.codesourcery.com/public/cxx-abi/abi.html#ctor-order]. If gcc switches from .ctors to .init_array, it needs to make sure to generate the constructors in forward order within the TU, rather than backwards order as it does in the .ctors section. I didn't see anything in HJ's patch that does that. We will still have an incompatibility with constructor order across TUs within an executable or shared library. The new order may be just as legal as the previous order according to the ABI and the language spec, but it will almost certainly cause previously-working code to fail. If we offer an option to switch from .ctors to .init_array, and encourage such code to use explicit priorities where order really matters, I'd think that would be OK.
