From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5134 invoked by alias); 13 Dec 2010 02:30:21 -0000 Received: (qmail 5121 invoked by uid 22791); 13 Dec 2010 02:30:19 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Mon, 13 Dec 2010 02:30:14 +0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ian at airs dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hjl.tools at gmail dot com X-Bugzilla-Target-Milestone: 4.6.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 Date: Mon, 13 Dec 2010 02:30:00 -0000 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: 2010-12/txt/msg01352.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #47 from Ian Lance Taylor 2010-12-13 02:29:46 UTC --- Jan Hubicka writes: > 1) is there any kind of any documented requirement on initialization of > static libraries? (i.e. is EABI fully standard conforming?) Not in C++. > 2) I believe that the backwarding order of .ctor section was concious > QOI issue. Yes. Some programs may implicitly rely on the fact that global constructors in archives linked later are run before constructors in the object linked against those archives. That is, given g++ foo.o -lbar where bar is a static archive, not a shared library, then currently the global constructors in objects pulled in from libbar.c will be executed before the global constructors in foo.o. That was an intentional choice because it is more likely to be correct than the reverse. However, the C++ standard does not guarantee it, so any programs which relies on this ordering is technically invalid. But of course it does not follow that we should break such programs for no reason. > 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. I don't know. Comment #1 refers to relative relocations. I'm sure which relocations this means. In a linked binary I would not expect to see any relocations in the .ctors section. As far as backward disk seeks, I assume this refers to the constructors that the program calls, not the .ctors section itself. The program will walk through the .ctors section forward to find then end and then backward to invoke the constructors, so no backward seek should be introduced there. So I assume the backward seek refers to the tendency of the constructors called earlier to be located later in the binary. I think the appropriate fix for this is better code positioning in the linker, which is completely in control. I'm not at all opposed to using .init_array, but changing the linker would be a better way to address this particular issue, as it would encourage such things as putting all the global constructors together rather than scattered across the program. As Mark says, obviously we can not switch to .init_array for code using constructor priorities unless we modify the linker. But I don't think that is a particularly big deal; we can continue to use .ctors for constructors with priorities and use .init_array for normal constructors, the latter case being vastly more common. Ian