From owner-svn-src-all@FreeBSD.ORG Sun May 13 03:28:01 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E360E1065674; Sun, 13 May 2012 03:28:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0BED8FC0A; Sun, 13 May 2012 03:28:00 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (unknown [24.114.252.231]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E8177B915; Sat, 12 May 2012 23:27:59 -0400 (EDT) Message-ID: <4FAF2A3F.5090708@FreeBSD.org> Date: Sat, 12 May 2012 23:27:59 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bruce Evans References: <201205111237.q4BCbGX2083596@svn.freebsd.org> <20120511124820.GN2358@deviant.kiev.zoral.com.ua> <6AE99277-D90F-453D-AE40-EE731DFD3BAB@FreeBSD.org> <20120511130955.GO2358@deviant.kiev.zoral.com.ua> <20120512014148.C1953@besplex.bde.org> In-Reply-To: <20120512014148.C1953@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 12 May 2012 23:28:00 -0400 (EDT) Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, David Chisnall , svn-src-head@freebsd.org, Gabor Kovesdan , Konstantin Belousov Subject: Re: svn commit: r235267 - in head/usr.bin/sort: . nls X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 03:28:01 -0000 On 5/11/12 1:17 PM, Bruce Evans wrote: > However, they may be some some boot programs that save space by not > bzeroing the bss. Not being a C program in this respect apparently > caused the following farcal churn in i386/boot2: > - the opts variable started with a bogus explicit initialization > to 0. Long ago (in 2003), but probably after the default of > -fzero-initialized-in-bss turned this into just a style bug, > the explicit initializaton was removed. > - zeroing of the bss was moved from i386/boot2/boot1.s ro rbx in 2004. > It hopefully still worked. > - in 2011, the kname variable was changed from char [1024] to a > pointer. The pointer was explicitly initialized to NULL. This > was not just a style bug, since the bss was apparently no > longer zeroed. > - initialization of the opts variable was apparently broken in the > same way some time before this (whenever the zeroing was optimized > away). > - in the next commit in 2011, it was claimed that the BSS is not > zeroed, and the initialization of kname was moved into main() > to fix this. bss was spelled BSS, so my greps didn't find this > immediately. > - in a later commit in 2012, the initialization of opts was moved into > main(), presumably for the same reason, but neither bss nor BSS was > mentioned in the commit log, so this took longer to find. > - these changes broke at least kname. Apparently, it can be initialized > to non-null before main() in some cases. This was fixed in the most > recent commit to boot2.c, in 2012, by moving the initialization of > kname out of main(). opts was moved similary. The commit message > doesn't mention bss or BSS, and says that this is to make clange > build again. But boot2 is compiled without -fzero-initialized-in-bss, > so initializing kname and opts outside of main() has no effect. They > are now uninitialized again, assuming that the 2011 commit message is > correct. Even the old char array for kname probably needed kname[0] > to be zero. We apparently depend on most memory being 0 when booting, > so that the chance of it being nonzero for these 2 variables is tiny. > > kname and opts are the only 2 global variables in i386/boot2 that need > to be initialized to 0 in some way (the others either need to be > initialized to non-0, so they never get put in the bss, or their initial > value doesn't matter. After reducing kname to a pointer, these variables > have total size 8. Perhaps the zeroing code would now take more than 8 > bytes. However, in the 2004 version when the zeroing code was in boot1.S, > it size seems to be 6 or 7 bytes (the code for this is smart). Thus the > savings might be negative, but they are more likely to be a whole 4-8 > bytes. There may be safer ways to save space. So I finally figured this out recently while looking at avg@'s recent patches. boot2's BSS is in fact zero'd by sys/boot/i386/btx/lib/btxcsu.S. This same code also zero's the BSS of /boot/loader. I have a patch to revert boot2 back to depending on the zero'd BSS in a tree, just need to commit it. -- John Baldwin