http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #75 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-17 14:47:27 UTC --- (In reply to comment #74) > We still have an unresolved issue here: we're effectively reversing the order > in which the ctors are run across translation units. While explicitly > undefined > by any standard, it was mentioned upthread that this would probably break a > lot > of code that depended on ctors for later translation units (e.g., a > statically-linked C++ library) running before those for earlier translation > units. And, in fact, we have been finding lots of such code. We've temporarily > worked around it by configuring GCC to continue to use .ctors sections, and by > turning off --ctors-in-init-array in the linker, but I'd think it would be > nice > to fix this. Can you provide a testcase? ARM EABI has been using .init_array from day one. How does it work for ARM EABI? > I'd like to propose a --reverse-init-array option to the linker that would > reverse the contributions to the .init_array section relative to one another > (but not the actual contents of each contribution). With this option, the > .init_array entries for translation unit A would come after those for > translation unit B, when A comes before B on the link command. This would > still > conform to the standards, but would provide a more reasonable ordering, since > it is natural to expect initializers for dependent libraries to execute before > those for code that depends on them (as is the case for shared libraries > already). > > As I recall the discussions from years ago when we first added .init_array, I > think we would have always preferred to have the dynamic loader execute the > .init_array entries in reverse, but we were trying to preserve the behavior > that had always been observed with the old .init section (which, obviously, > could not execute in reverse). I believe that was the original reason (or at > least part of it) that GCC put ctors in a separate section rather than using > .init or .init_array. Now that we're moving .ctors into .init_array, I think > it's more important to preserve the old behavior of ctors rather than the old > behavior of .init fragments. > > HJ, if I add this option to gold, would you add it to ld? > > If this is OK with everyone, we can then discuss whether or not the option > should be on by default. > I think we should preserve the old behavior as much as we can, by default. --reverse-init-array should be the default. Thanks.
