[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

ccoutant at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Dec 13 20:24:00 GMT 2010


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.



More information about the Gcc-bugs mailing list