Re: Bug in loadfile_elf32.c?

On Wed, 31 Aug 2016, Erik Fair wrote:

> The OpenBoot firmware (IEEE 1275) on SPARCs & UltraSPARCs only initializes as much RAM as the NVRAM parameter variables specify, not all RAM that is detected. It tends to be a tradeoff - zeroing all RAM when you’ve got gigabytes “takes a long time” and some places want fast (re)booting, so “do just enough for the kernel” has long been common practice.
> 
> In principle, once the OS kernel is booted (whatever it is), all parity/ECC RAM should be initialized (if there’s random bits in a RAM location, reading it might raise an exception), but it can be done by “lazy evaluation” (as needed) rather than all-at-once in a blocking fashion.

Be that as is may, it's not really a 1275 issue, it's buggy C code.  The C 
language does not specify automatic variables are initialized, so the 
original code was buggy.  It's a miracle it ever worked at all.  Stack use 
by any other functions in the boot loader could also have left garbage on 
the stack which would cause random behavior.

The marks array either needs to be explicitly initialized before calling 
load_file, or switched to a static variable which would be initialized as 
part of zeroing out the BSS segment.

Eduardo