From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13856 invoked by alias); 17 Apr 2012 01:22:45 -0000 Received: (qmail 13804 invoked by uid 22791); 17 Apr 2012 01:22:44 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Apr 2012 01:22:31 +0000 From: "ccoutant at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them Date: Tue, 17 Apr 2012 01:22:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ccoutant at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hjl.tools at gmail dot com X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg01349.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Cary Coutant changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ppluzhnikov at google dot | |com --- Comment #74 from Cary Coutant 2012-04-17 01:21:47 UTC --- 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. 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. -cary