[U-Boot-Users] Why are some global vars part of the image, and some not?

[Timur Tabi <timur@freescale.com>]

Jerry Van Baren wrote:
> Scott Wood wrote:
>> Jerry Van Baren wrote:
>>> Does the linker create proper zero initialization?
>> Yes.
> 
> [snipped the rest of the "yes" answers - good to know this, thank you]
> 
>> The main things that would take effort are changing all the board linker 
>> scripts, and finding large BSS allocations and changing them to be 
>> dynamically allocated so they don't take up space in flash.
>>
>> The benefit is that bss-related bugs in the pre-RAM code go away and 
>> stay away, and that ugliness such as having to specify __attribute__ 
>> ((section ("data"))) whenever the value is zero also goes away.
>>
>> -Scott
> 
> OK, but you are trading one fixed bss-related bug in the pre-RAM code 
> for a larger u-boot image and more complexity.

No, I don't think that's accurate.

Advantages:

1) Eliminates the one (there may be more in the future) BSS-related bug
2) Eliminates the BSS initialization code
3) It's LESS complex.  I don't know why you think it's more complex.
4) Eliminates the obscure bug that could occur if you expect "int X = 0" to 
actually be 0 instead of 0xFFFFFFFF.

Disadvantes:

1) Larger U-Boot image file.
2) Larger flash storage requirements.

> Pre-RAM code is short and sweet and thus has a pretty limited 
> opportunity for bugs.  On the other hand, changing all the board linker 
> scripts takes effort and regression testing by all the board 
> maintainers.  

I agree that making the change globally would require regression testing.  For 
instance, there could be buggy code out there that depends on the BSS section 
being initialized to FF before the relocation.

> Finding large bss allocations and changing them to be 
> dynamically allocated sounds like a job that is initially large and 
> ultimately never ending.

It could be implemented as a compile-time option that would be disabled by 
default.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale