From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28739 invoked by alias); 14 Apr 2003 18:41:43 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 28724 invoked from network); 14 Apr 2003 18:41:41 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 14 Apr 2003 18:41:41 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h3EIfdV13115; Mon, 14 Apr 2003 14:41:39 -0400 Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.8/8.12.8) with ESMTP id h3EIfcpp007556; Mon, 14 Apr 2003 15:41:38 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.8/8.12.8/Submit) id h3EIfYnV007552; Mon, 14 Apr 2003 15:41:34 -0300 To: Hal Black Cc: binutils Subject: Re: [BUG] ld behavior varies for C++ static initializer depending on .a or .o input References: <3E9639F9.9050503@vt.edu> <3E978F84.4050603@vt.edu> <3E98219D.7010506@ieee.org> <3E98546A.9060507@ieee.org> <3E98C756.30005@ieee.org> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Mon, 14 Apr 2003 18:41:00 -0000 In-Reply-To: <3E98C756.30005@ieee.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00317.txt.bz2 On Apr 12, 2003, Hal Black wrote: > I'm not an expert on g++ symbols, but I'm assuming the static > intializer of the sort I'm talking about is is named > __static_initialization_and_detruction.* because that's what nm > reports for my test program. Watch out for .ctor, .init or .init_array sections as well. > I just hadn't heard any valid reasons against having it be as I > describe, and it seems like the correct interpretation of the spec. I disagree. The compiler, which is the entity that deals with translation units, isn't dropping any initializers, just like mandated by the spec. Now, by the Standard, a program is one or more translation units linked together [basic.link], and that's it. Nowhere does it get into details of what a linker is, nevermind how static archives should behave, since this is all far beyond the scope of the C++ Standard. Your point that archives should be scanned for initializers would be perfectly reasonable, except for the bloat one wouldn't be able to avoid, but, like Ian says, this is not the way linkers have dealt with archives in the past and, barring a strong reason to change, they should change. Standard compliance is not such a reason, because the nowhere does the standard determine how to select the translation units that go into a program. > Based on an earlier portion of your reply, I am taking your > interpretation to mean that a static initializer in a library is only > called when something references an instance of its class or members, > but not otherwise. I don't believe this is a valid view from reading > the C++ spec. My interpretation is that a static initializer in a translation unit is only executed if the translation unit makes it to the program. The point under debate is whether the translation unit must make it to the program in spite of not being referenced by any other translation unit listed in the program. If you have such requirements, using an archive is the wrong approach: you want to list the object files instead. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer