On 11/20/2017 11:19 AM, Christian Borntraeger wrote:
On 11/20/2017 11:16 AM, Alexander Graf wrote:
On 11/20/2017 11:02 AM, Christian Borntraeger wrote:
On 11/20/2017 10:29 AM, Alexander Graf wrote:
On 11/20/2017 10:27 AM, Christian Borntraeger wrote:
On 11/20/2017 10:19 AM, Alexander Graf wrote:
On 11/20/2017 10:15 AM, Christian Borntraeger wrote:
The QEMU ELF loader does not initialize the bss segment. This has
triggered several bugs in the past, e.g. see commit 5d739a4787a5
("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize
css").
Instead of fixing these things one-by-one we can build the BIOS
with -fno-zero-initialized-in-bss. This will move the zero variables
also into the data segment, which is then part of a LOAD section.
Doesn't this bloat the firmware? Why don't we just manually clear bss in the
firmware itself? It's what all other firmwares do :)
Yes the proper fix is to initialize bss in the bios itself.
I was trying to come up with something for 2.11, but since the patch does not
solve the original issues, lets drop it.
Initializing bss is quite simple. You can probably even do it from C. Just set
two variables before and after .bss in the linker script and memset(0) from
start to end :).
Yes, I know but then we have to change the build process to use a linker
script.(we rely on the default
linker script right now).
I'm not sure how common generic linker scripts are, but in our default script we have
existing markers for bss and end. You can look at the default linker script using gcc
<c file> -Wl,-verbose. This simple source worked for me:
Are we sure that the range between __bss_start and _end does not include other
elements (besides bss)?
It seems to be the intended semantic for the linker script I see as
default, but I'm not an expert here :). Can you check with Uli?
Alex
