[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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> 2010-12-11 18:46:48 UTC ---
(In reply to comment #14)
> H.J. --
> 
> Some of the statements that you're making in Comment #11 are inaccurate or
> unclear:
> 
> Given:
> 
>   Foo foo(...);
>   Bar bar(...);
> 
> within a single module, the C++ standard guarantees that foo is initialized
> before bar.  See \S 3.6.2 "Initialization of non-local objects":
> 
> "Other objects defined in namespace scope have ordered initialization. Objects
> defined within a single translation unit and with ordered initialization shall
> be initialized in the order of their definitions in the translation unit."
> 
> Now, it is true that if foo or bar is zero-initialized or constant-initialized
> (these are terms of art in the C++ standard) that initialization happens before
> dynamic initialization, so given:
> 
>   Foo foo(...);
>   int i = 3;
> 
> It is guaranteed that "i" is initialized before "foo".  But, even in that case,
> the order is well-defined; it's just not necessarily the order in which the
> objects are declared.

Thanks for correction/clarification.

> Although the C++ standard does not impose requirements on initialization order
> across translation units (i.e., source files), there is no doubt that programs
> accidentally or intentionally depend upon it.  I'm sure that making changes in
> this regard will break something.  But, such breakage is akin to the breakage
> that occurs whenever we optimize more aggressively; people depend on current
> undocumented behaviors, and programs break when we make a change.  So, I don't
> think we should resist making the change to .init_array simply on this ground.

That is very true, specially for LTO.

> On the other hand, we do have an issue around constructor priorities.  If I
> recall correctly, the linker sorts all of the .ctors.NNNNN sections into a
> single array which is then executed in order.  So, if the program has some
> object files built using .ctors.NNNNN and others using .init_array, I don't see
> how we can get the interleaving that is specified in the source code.

Linker supports sorting .ctors.NNNNN and .init_array.NNNN.
Within .ctors.NNNNN and .init_array.NNNN, the order is defined.
And ctors.NNNNN will be called before .init_array.NNNN. If you
have constructor priorities in .o files and .c files, you may
get different behaviors if .o files are compiled with a different
compiler, different versions of GCC or not GCC at all.