svn commit: r235267 - in head/usr.bin/sort: . nls

[John Baldwin]

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