From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25452 invoked by alias); 13 Apr 2003 02:11:36 -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 25445 invoked from network); 13 Apr 2003 02:11:35 -0000 Received: from unknown (HELO mail.hal.cx) (68.32.53.147) by sources.redhat.com with SMTP; 13 Apr 2003 02:11:35 -0000 Received: from ieee.org (unknown [192.168.0.108]) by mail.hal.cx (Postfix) with ESMTP id F04A12EE12 for ; Sat, 12 Apr 2003 22:11:34 -0400 (EDT) Message-ID: <3E98C756.30005@ieee.org> Date: Sun, 13 Apr 2003 02:11:00 -0000 From: Hal Black User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030328 X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00289.txt.bz2 Alexandre Oliva wrote: > On Apr 12, 2003, Hal Black wrote: > > >>>That would mean that every static initializer in a .a file would be >>>brought in > > >>Yes, as desired. > > > Maybe in your specific application. But think of the Standard C++ > library. It may contain hundreds, if not thousands, of global > initializers, that are of no use for most programs that don't happen > to use the particular feature that depend on some of these > initializers. 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. When I run nm on libstdc++*.a and grep for static_initialization, I get not thousands, not hundreds, but zero matches. So, if I'm right about the naming, the program would get no bigger if the changes I suggested were implemented. OTOH, I could be totally wrong. 8') I really know nothing about the details of how g++ does naming of C++ constructs. [caveat: I don't have access to the latest stuff right now, this is with mandrake 9.0 - maybe they have added thousands of static initializers since then] I counted 18 static initializers total in /usr/lib. I don't know whether these are meant to be called every time the library is linked against, or just when a certain feature is used. > Bringing them in just because you would like it to be > so is not exactly a reasonable proposition. It's not a question of me liking it to be so. I have already stated that I am fine with the work around. I am raising the point how the C++ spec is interpreted in terms of libraries for discussion. The way to dispute this point is to argue against the point, not wave it off because you infer endearment of an individual to it, which is irrelevant on whether it is the right way to do it or not. 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. >>If you don't think this is the proper usage, what is your >>interpretation of the meaning of having a static intializer (or items >>with static storage duration in general) in a library? > > > No different from having it in an object file: if the object file is > linked in, the static initializer is run. The difference is that > object files listed in the command line are always linked in, whereas > those in a static library get linked in only if they would resolve > some symbol the linker is looking for. I understand the behavior of the tools. What I asked was what is the meaning of having objects with static storage in a library. 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 claim is that if it has a static initializer, it is required. > > > If we implemented this mis-feature, you'll come back tomorrow and > complain about the bloat from all these modules being linked in that > are not needed for your program to run, and the answer will be that > they do contain static initializers so, per your request, they have to > be brought in. If they were not needed for the program to run, the behavior (not counting performance/memory footprint for the moment) would be the same whether they were included or not. Desired side-effects of the static initializers don't happen when they're not included, therefore they are required for the program to run. I see your point that if the custom is to put in instances of static storage whose initializers aren't meant to be called all the time, some uneccesary bloat could result. If they are supposed to be called, however, they aren't unneccesary. I don't know whether the 18 static initializers in my /usr/lib are meant to be used the way I describe or the way you describe, so I can't say whether these are unneccesary or neccesary. Regardless, if my interpretation of the C++ spec is correct, it is a flaw in the library to create static storage items with initializers with side effects that aren't meant to be run for all users of the library. In that case, the linker would be following the spec and would deserve no complaints. It's not the auto-maker's fault if the car is working fine and you get caught speeding. But, if you don't want to implement it to avoid complaints, it's your project, not mine, so I can't argue with that.