On 4/26/10 10:29 PM, Blue Swirl wrote:
On 4/26/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Segher Boessenkool wrote:
That patch [which doesn't display in the mail archive btw] seems to remove -print-libgcc-file-name, and uses -lgcc instead -- not such a hot idea?
I don't even know how to build OpenBIOS, so I'm not going to fix it,
sorry.
If you have a PPC cross-compiler installed, the build is easy:
./config/scripts/switch-arch cross-ppc make
Then copy the resulting binary from obj-ppc/ into your share/qemu directory.
I'll do my best with directed questions of course :-)
Even an idea as to what to look at first would be a great help...
I think I can now reproduce the crash, previously I had no problems which made debugging a bit difficult. I changed gcc's memory model flag to -mcmodel=medlow and now Milax crashes in __umodti3 like Igor reported. Perhaps this flag may be different when gcc builds libgcc.
The problem seems to be that gcc's libgcc divides by zero. Breakpoint 10, __umodti3 (u=<value optimized out>, v=0x0000000000000000fffffffffffffffe) at ../../gcc/libgcc2.c:911 911 in ../../gcc/libgcc2.c 11: $i4 = 0x0 10: $i0 = 0x1 1: x/i $pc 0xffd1f980 <__umodti3+952>: udivx %i0, %i4, %g1
Why this doesn't happen with our libgcc? Why it doesn't happen with -mcmodel=medany? What a puzzle.
One solution could be to check for division by zero in mudivmod(), which is where __umodti3 is called from.
Changing the code model most likely changes the ABI, so it's no wonder it does not work anymore. The same thing happens if your gcc is compiled with a different "regparm" setting than your code.
This was generally reported to the gcc folks last year but I think nothing has happened since then: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
In coreboot we fixed the regparm issue by using a wrapper that converts between the ABIs:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/arch/i386/Makefi... http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/lib/gcc.c
Not sure whether something similar is possible for the code model, too, but it sounds less trivial. So until then the GCC folks' answer is: If your code uses compile time options that change the ABI of your compiler, you need to compile a compiler (well, libgcc) with those options, too. So the simplest way is just not assuming any ABI details if possible and not using CFLAGS that change the default ABI.
Stefan