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

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

Cary Coutant <ccoutant at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot
                   |                            |com

--- Comment #74 from Cary Coutant <ccoutant at gcc dot gnu.org> 2012-04-17 01:21:47 UTC ---
We still have an unresolved issue here: we're effectively reversing the order
in which the ctors are run across translation units. While explicitly undefined
by any standard, it was mentioned upthread that this would probably break a lot
of code that depended on ctors for later translation units (e.g., a
statically-linked C++ library) running before those for earlier translation
units. And, in fact, we have been finding lots of such code. We've temporarily
worked around it by configuring GCC to continue to use .ctors sections, and by
turning off --ctors-in-init-array in the linker, but I'd think it would be nice
to fix this.

I'd like to propose a --reverse-init-array option to the linker that would
reverse the contributions to the .init_array section relative to one another
(but not the actual contents of each contribution). With this option, the
.init_array entries for translation unit A would come after those for
translation unit B, when A comes before B on the link command. This would still
conform to the standards, but would provide a more reasonable ordering, since
it is natural to expect initializers for dependent libraries to execute before
those for code that depends on them (as is the case for shared libraries
already).

As I recall the discussions from years ago when we first added .init_array, I
think we would have always preferred to have the dynamic loader execute the
.init_array entries in reverse, but we were trying to preserve the behavior
that had always been observed with the old .init section (which, obviously,
could not execute in reverse). I believe that was the original reason (or at
least part of it) that GCC put ctors in a separate section rather than using
.init or .init_array. Now that we're moving .ctors into .init_array, I think
it's more important to preserve the old behavior of ctors rather than the old
behavior of .init fragments.

HJ, if I add this option to gold, would you add it to ld?

If this is OK with everyone, we can then discuss whether or not the option
should be on by default.

-cary