From owner-freebsd-sparc64@FreeBSD.ORG Sun Sep 15 14:15:06 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8BEEC75C; Sun, 15 Sep 2013 14:15:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C75F23AF; Sun, 15 Sep 2013 14:15:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MT6005006N9HK00@smtpauth4.wiscmail.wisc.edu>; Sun, 15 Sep 2013 09:14:59 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.15.140615, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (unknown [76.210.60.217]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MT6004HH7KXYU00@smtpauth4.wiscmail.wisc.edu>; Sun, 15 Sep 2013 09:14:59 -0500 (CDT) Message-id: <5235C0E1.9080009@freebsd.org> Date: Sun, 15 Sep 2013 09:14:57 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130907 Thunderbird/17.0.8 To: Eitan Adler Subject: Re: Patch for Cross-Reference Phandles References: <522CC7E0.9060508@freebsd.org> <5231D8A6.9080501@freebsd.org> <20130914133155.GA32845@alchemy.franken.de> <52346D71.4080407@freebsd.org> <1379173405.1197.7.camel@revolution.hippie.lan> <20130914172735.GX68682@funkthat.com> <1379181341.1197.26.camel@revolution.hippie.lan> In-reply-to: Cc: Ian Lepore , "freebsd-arm@freebsd.org" , freebsd-sparc64 , FreeBSD PowerPC ML X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:15:06 -0000 On 09/14/13 19:04, Eitan Adler wrote: > [ *please* bottom post ] > > On Sat, Sep 14, 2013 at 7:56 PM, Adrian Chadd wrote: >> ... holy crap. :-) >> >> erm, try writing some code that does something with it: >> >> int foo[2] = { 0, 0 }; >> >> main() >> { >> int i; >> for (i = 0; i < 2; i++) { >> foo[i] = i; >> } >> } >> >> .. and then make foo[2] be foo[512] and explicitly set it up to be zero'ed. >> see what happens. > With an explicit zeroing: > > text data bss dec hex filename > 1572 484 16 2072 818 a.out > > Without: > > text data bss dec hex filename > 1572 484 16 2072 818 a.out > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" There's an explanation of this behavior attached to the -fno-zero-initialized-in-bss argument to GCC. I've pasted the relevant section of the man page below: -fno-zero-initialized-in-bss If the target supports a BSS section, GCC by default puts variables that are initialized to zero into BSS. This can save space in the resulting code. This option turns off this behavior because some programs explic- itly rely on variables going to the data section. E.g., so that the resulting executable can find the beginning of that section and/or make assumptions based on that. The default is -fzero-initialized-in-bss. This is why I wasn't worried about the = 0... -Nathan