[LinuxBIOS] [PATCH] v3: Crash with a descriptive message in case of compiler bugs

[Carl-Daniel Hailfinger]

On 01.12.2007 13:10, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> Ron mentioned he had strange hangs in pll_reset on various targets. This
>>> may be due to miscompilation of XIP objects which do not have
>>> _MAINBOBJECT defined. This issue was impossible to see on qemu because
>>> no such object existed. Introduce initram_printktest.c in the Qemu
>>> target, which will test for miscompilation and crash with a descriptive
>>> error message.
>>>
>>> This has been build tested and runtime tested on Qemu, and with my
>>> compiler/linker combination it indeed crashes.
>>> gcc (GCC) 4.2.1 (SUSE Linux)
>>> GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
>>>
>>> Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and
>>> the linker above had exactly the same results.
>>>
>>> Unless we manage to fix the bug uncovered by this patch, leaving the
>>> Qemu target in crashing state is the best thing we can do because this
>>> behaviour mirrors the state of all other targets.
>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>>
>>> (don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c"
>>> if you commit)
>>>   
>>>     
>>>       
>> Ack anyone? I have another patch which fixes the bug revealed by this
>> patch, but I want to commit them in separate steps to make it more
>> obvious that one patch points out the problem, and one is a possible
>> solution.
>>
>>
>> Regards,
>> Carl-Daniel
>>
>>   
>>     
> I think this is rather an experiment and should not be committed in this
> way. It's not a functionality of LinuxBIOS. Do we really need this?
>   

If you want to boot v3 on any hardware target, yes. The reason Ron is
seeing crashes in pll_reset is exactly the same reason why this patch
causes a crash as well. Basically, we not only use the wrong compiler
options for initram, we also use the wrong linker options for initram.
Both happen to work by accident in combination, but only for the Qemu
target. Once the patch is applied, Qemu behaviour mirrors hardware
target behaviour.

Oh, and btw, the gcc behaviour we depend on is undocumented and
partially undefined and may change with the moon phase. The patch
actually gives us a chance to verify later that gcc did what we wanted.
And yes, i have code for that as well. But committing just the "fix"
without the Qemu target modifications leaves those testing with real
hardware with heavy problems once the "fix" is no enough anymore to
invoke moon-phase-dependent behaviour of gcc.

Regards,
Carl-Daniel