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. Reported-by: Thomas Huth <th...@redhat.com> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> --- pc-bios/s390-ccw/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile index 6d0c2ee..2687590 100644 --- a/pc-bios/s390-ccw/Makefile +++ b/pc-bios/s390-ccw/Makefile @@ -12,7 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/s390-ccw) OBJECTS = start.o main.o bootmap.o sclp.o virtio.o virtio-scsi.o virtio-blkdev.o QEMU_CFLAGS := $(filter -W%, $(QEMU_CFLAGS)) QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks -msoft-float -QEMU_CFLAGS += -march=z900 -fPIE -fno-strict-aliasing +QEMU_CFLAGS += -march=z900 -fPIE -fno-strict-aliasing -fno-zero-initialized-in-bss QEMU_CFLAGS += $(call cc-option, $(QEMU_CFLAGS), -fno-stack-protector) LDFLAGS += -Wl,-pie -nostdlib -- 2.9.4
