In message 454F992D.7010402@freescale.com you wrote:
Advantages:
- Eliminates the one (there may be more in the future) BSS-related bug
Let's keep this straight. The bug is not in U-Boot, but in newly introduced code, which ignores the documented way to write code that is running in the restrictred environment before relocation.
- Eliminates the BSS initialization code
Yes, what a win. We save 50 bytes of code and add - wait a second:
-> size u-boot text data bss dec hex filename 328632 30584 314076 673292 a460c u-boot
...and add 307 KiB of data. You lose by one to several thousands.
- It's LESS complex. I don't know why you think it's more complex.
- Eliminates the obscure bug that could occur if you expect "int X = 0" to
actually be 0 instead of 0xFFFFFFFF.
You don't understand. No matter what your're trying to do, pre- relocation code runs in a severly restricted environment. All your attapts to "fix" this are void, especially since the whole data segment remains read-only. Solving the "int X=0;" case does not solve the "X=1;" five lines later.
You have to be aware of this situation, and trying to hide it by providong a "working solution" for a single special case is making things more obscure.
I recommend just to keep in mind *all* the restrictions when writing pre-reloc code, and to minimize the amount of such code in your systems.
Anything else is probably worse than what we have now.
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.
You speculations are ... ummm... interesting. You find funny ways to defend a situatioin where the problem is all your's only.
It could be implemented as a compile-time option that would be disabled by default.
No. I will not accept any of such code. Period.
Best regards,
Wolfgang Denk