svn commit: r235267 - in head/usr.bin/sort: . nls
jhb at FreeBSD.org
Sun May 13 03:28:01 UTC 2012
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  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
> - 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
> - 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
> 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.
More information about the svn-src-head