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

["ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #47 from Ian Lance Taylor <ian at airs dot com> 2010-12-13 02:29:46 UTC ---
Jan Hubicka <hubicka@ucw.cz> writes:

>   1) is there any kind of any documented requirement on initialization of
>      static libraries? (i.e. is EABI fully standard conforming?)

Not in C++.

>   2) I believe that the backwarding order of .ctor section was concious
>      QOI issue.

Yes.  Some programs may implicitly rely on the fact that global
constructors in archives linked later are run before constructors in the
object linked against those archives.  That is, given
    g++ foo.o -lbar
where bar is a static archive, not a shared library, then currently the
global constructors in objects pulled in from libbar.c will be executed
before the global constructors in foo.o.  That was an intentional choice
because it is more likely to be correct than the reverse.  However, the
C++ standard does not guarantee it, so any programs which relies on this
ordering is technically invalid.  But of course it does not follow that
we should break such programs for no reason.

>      I wonder how much legacy code this might break when static
>      libraries start initializing after main modules.
>      i686-linux execute a lot more code than EABI.

I don't know.


Comment #1 refers to relative relocations.  I'm sure which relocations
this means.  In a linked binary I would not expect to see any
relocations in the .ctors section.

As far as backward disk seeks, I assume this refers to the constructors
that the program calls, not the .ctors section itself.  The program will
walk through the .ctors section forward to find then end and then
backward to invoke the constructors, so no backward seek should be
introduced there.  So I assume the backward seek refers to the tendency
of the constructors called earlier to be located later in the binary.  I
think the appropriate fix for this is better code positioning in the
linker, which is completely in control.  I'm not at all opposed to using
.init_array, but changing the linker would be a better way to address
this particular issue, as it would encourage such things as putting all
the global constructors together rather than scattered across the
program.

As Mark says, obviously we can not switch to .init_array for code using
constructor priorities unless we modify the linker.  But I don't think
that is a particularly big deal; we can continue to use .ctors for
constructors with priorities and use .init_array for normal
constructors, the latter case being vastly more common.

Ian