http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> 2010-12-11 15:01:34
UTC ---
> 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?)
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.
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.
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.
Honza
