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)?
>
>
> #include <stdio.h>
>
> extern char __bss_start[];
> extern char _end[];
>
> int main(void)
> {
> printf("BSS size: %lx\n", (long)_end - (long)__bss_start);
> return 0;
> }
>
>
>
> Alex
>
>
