From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15412 invoked by alias); 10 Feb 2005 15:58:41 -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 15310 invoked from network); 10 Feb 2005 15:58:35 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org with SMTP; 10 Feb 2005 15:58:35 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 15:58:34 +0000 From: "Dave Korn" To: "'Virgil Anuichi'" , "'Alan Modra'" Cc: Subject: RE: wrong initialized global variable (in the wrong section: .bss instead of .data) Date: Thu, 10 Feb 2005 19:04:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20050210140711.36117.qmail@web21002.mail.yahoo.com> Message-ID: X-OriginalArrivalTime: 10 Feb 2005 15:58:34.0792 (UTC) FILETIME=[60254A80:01C50F89] X-SW-Source: 2005-02/txt/msg00206.txt.bz2 > -----Original Message----- > From: binutils-owner On Behalf Of Virgil Anuichi > Sent: 10 February 2005 14:07 > The initialization is not zero. And that's the > problem. In fact, a global looking like int foo=0; > would come up with an undidefined value, in the .bss. The .bss section is cleared to zero by the runtime startup code, so I suspect your problem is to do with that. Are you using -nostdlib or -nodefaultlibs (or even -nostartfiles)? Both those flags exclude the C runtime startup files from the link. > I actually dig some more and it's not the linker > script, rather the compiler. The objdump shows me even > the .o file has the global in the .bss section. The > old compiler works fine: it puts it in .data section. > All initialized globals seem to be put in the .bss > with the exception of the globals initialized with a > constant (?). > For instance int foo=0; ends up in .bss > while > int foo1=TICK_1; ends up in .data > Again, the old gcc compiler sets all of them in .data. Above, you said that "the initialisation is not zero", but the example you have here, you say that zero-inited variables end up in .bss and non-zero-inited variables end up in .data, and that is the correct behaviour, by design. If you wish to change it, the -fno-zero-initialised-in-bss flag that Alan mentioned will move the zero initialised variables into the .bss section for you. cheers, DaveK -- Can't think of a witty .sigline today....