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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> 2010-12-11 15:34:41 UTC ---
(In reply to comment #10)
> > This explanation doesn't stand: for instance, ARM EABI exclusively uses
> > .init_array, and the execution order for those is forward. And when linking
> > static libraries, the order of the function pointers in the section is strictly
> > growing, which means libraries are being initialized last.
> 
> I noticed that EABI is reversed versus .ctor/.dtor ABIs.  So I guess we need to
> decide
> 
>   1) is there any kind of any documented requirement on initialization of
>      static libraries? (i.e. is EABI fully standard conforming?)

There is no difference in initialization between linking
against libfoo.a vs foo.o.

>   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.

>      i686-linux execute a lot more code than EABI.
> 
> Note that we make the situation bit worse than EABI has as the scheme is not
> strictly backwards or strictly forwards, but combination of both depending what
> compiler built the code. This probably does not make much of practical
> difference.

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

---
Foo foo;
Bar bar;
---

> Said that, I am personally happy with the patch and see how it should
> noticeably
> improve C++ startup times even with the recent ctor/dtor grouping code. Even if
> we
> basically eliminate the backward reading in text section, we still will have
> tendency
> to initialize data segment in backwarding order.
> 
> I would like to hear opinion of someone who knows how these things was
> introduced (Iant, hopefully?) and if the patch is going to 4.6.0, I think we
> should get approval from one of our release managers.  It is bit late for this
> patch now, though I think it qualify being a patch affecting one target only.
> 

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.