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

["hjl.tools at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2010-12-11 16:53:41 UTC ---
(In reply to comment #12)
> > >   2) I believe that the backwarding order of .ctor section was concious
> > >      QOI issue.  I wonder how much legacy code this might break when static
> > >      libraries start initializing after main modules.
> > 
> > Static libraries are LINKED INTO main module. I don't understand
> > this question.
> 
> I meant the object files that are not in the library. By the way linker works,
> first placing the object files it is given and then resolving dependencies by
> getting more from the libraries, the reverse initialization order ensure that
> the object files from libraries are initialized before object files needing
> them.

Not necessarily. You can have

... y.o -lbar x.o -lfoo z.o -lbar -lfoo ...
... y.o --start-group -lbar x.o -lfoo --end-group ...

As a linker developer, I will say what you described depends on
command line options. We never guarantee that constructors in
libbar.a will be called in any particular order relative to
constructors in any other object files.

> > My patch guarantee the relative order of constructors vs. destructors,
> > as we do now. GCC never guarantees the order of constructors. Please note'
> > that even within single source file, there is no guarantee that foo will
> > be initialized before bar in
> 
> Yes, I know that within single file the order is undefined.  All I am concerned
> about are the libraries. 
> > 
> > I worked with Cary on the .init_array gABI spec and implemented
> > it in gas/ld/glibc.  I am the person who knows how these things was
> > introduced and how they work.
> 
> OK, do you know why the order of execution of .ctor was chosen to be reversed
> even if it would make more sense to reverse .dtors?
> 

I agree that the order looks odd. That was chosen when the g++ compiler
was first implemented almost 20 years ago. Without .init_array, we had
to do all those crazy stuff in crt*.o. We never bothered to change it.
However, the order shouldn't make a difference.  That is

# gcc foo.o bar.o
# gcc bar.o foo.o

should work the same way.

We introduced .init_array into gABI 10 years ago so that we can avoid
those crazy things in crt*.o.  It is the time now to switch for Linux/x86/