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@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