Date: Sat, 12 May 2012 23:27:59 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, David Chisnall <theraven@freebsd.org>, svn-src-head@freebsd.org, Gabor Kovesdan <gabor@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: svn commit: r235267 - in head/usr.bin/sort: . nls Message-ID: <4FAF2A3F.5090708@FreeBSD.org> In-Reply-To: <20120512014148.C1953@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FAF2A3F.5090708>