From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31618 invoked by alias); 22 Apr 2012 21:19:15 -0000 Received: (qmail 31605 invoked by uid 22791); 22 Apr 2012 21:19:13 -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; Sun, 22 Apr 2012 21:19:01 +0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them Date: Sun, 22 Apr 2012 21:19: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: ian at airs dot com 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: 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/msg01865.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #102 from Ian Lance Taylor 2012-04-22 21:16:14 UTC --- To be clear, nothing has changed in collect2. The only thing that has changed is that data that was being emitted in the .ctors section is now being emitted in the .init_array section (and similarly for .dtors and .fini_array). The reason this makes a difference is that the dynamic linker executes the entries in .init_array, whereas gcc-provided startup code executes the entries in .ctors. And they happen to execute the entries in different orders. The whole point of the change is in fact to execute the entries in a different order, though I continue to think that this would be better handled in a different way. In other words, it is not the case that gcc is producing an anoymous opaque object that the linker can not change.