... is the message I get from QEMU's official ppc OpenBIOS blob. sparc and sparc64 blobs work better.
Probably the ppc blob just needs updating. My cross-compilation is still running to confirm whether HEAD works better.
Some notes: binutils 2.20.1 and 2.20 do not compile on Mac OS X v10.6. They error about lots of _("...") format strings that Ubuntu (gcc 4.4.1) just warns about. OSX default gcc is 4.2.1; CC=gcc-4.0 leads to /usr/lib/iconv.la not found during linking instead.
Andreas
Andreas Färber wrote:
... is the message I get from QEMU's official ppc OpenBIOS blob. sparc and sparc64 blobs work better.
Probably the ppc blob just needs updating. My cross-compilation is still running to confirm whether HEAD works better.
Yes. This was fixed in r734. Note there is still an issue whereby direct boot under PPC seems to have a problem with the console - it appears to hang, but in fact just the console I/O is blocked. I've spent several hours on this, but have yet to find the cause.
If you can extract the CHRP boot command, then invoking "load" on the correct path and then typing "go" still works fine.
Some notes: binutils 2.20.1 and 2.20 do not compile on Mac OS X v10.6. They error about lots of _("...") format strings that Ubuntu (gcc 4.4.1) just warns about. OSX default gcc is 4.2.1; CC=gcc-4.0 leads to /usr/lib/iconv.la not found during linking instead.
Thanks for the heads-up, although you're probably asking the wrong people ;)
ATB,
Mark.
Hi,
Am 10.04.2010 um 18:26 schrieb Andreas Färber:
Some notes: binutils 2.20.1 and 2.20 do not compile on Mac OS X v10.6. They error about lots of _("...") format strings that Ubuntu (gcc 4.4.1) just warns about. [...]
--disable-werror was able to workaround that much easier than editing the sources, thanks for the hint.
Configuration now is: Mac OS X v10.6.3 (i386) w/ gcc 4.2.1 gmp 5.0.1 mpfr 2.4.2 mpc 0.8.1 binutils 2.20.1 w/ --target=powerpc-elf --disable-nls gcc 4.5.0 w/ --target=powerpc-elf --disable-nls --disable-libssp
Build fails as follows:
Building OpenBIOS for ppc Building...error: /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/string.c: 499: undefined reference to `_restgpr_30_x' liblibc.a(string.o): In function `strcasecmp': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/string.c: 513: undefined reference to `_restgpr_27_x' liblibc.a(string.o): In function `strncasecmp': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/string.c: 527: undefined reference to `_restgpr_26_x' liblibc.a(vsprintf.o): In function `number': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/vsprintf.c: 145: undefined reference to `_restgpr_17_x' liblibc.a(vsprintf.o): In function `vsnprintf': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/vsprintf.c: 388: undefined reference to `_restgpr_21_x' libgcc.a(__divdi3.o): In function `__divdi3': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/ __divdi3.c:8: undefined reference to `_savegpr_31' /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/ __divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/ __udivmoddi4.c:31: undefined reference to `_restgpr_30_x' make[1]: *** [openbios-qemu.elf] Error 1 make: *** [build] Error 1
Anyone else noticed that on another system? Is it a GCC bug or are changes to OpenBIOS code required?
Regards,
Andreas
Andreas Färber wrote:
Hi,
Am 10.04.2010 um 18:26 schrieb Andreas Färber:
Some notes: binutils 2.20.1 and 2.20 do not compile on Mac OS X v10.6. They error about lots of _("...") format strings that Ubuntu (gcc 4.4.1) just warns about. [...]
--disable-werror was able to workaround that much easier than editing the sources, thanks for the hint.
Configuration now is: Mac OS X v10.6.3 (i386) w/ gcc 4.2.1 gmp 5.0.1 mpfr 2.4.2 mpc 0.8.1 binutils 2.20.1 w/ --target=powerpc-elf --disable-nls gcc 4.5.0 w/ --target=powerpc-elf --disable-nls --disable-libssp
Build fails as follows:
Building OpenBIOS for ppc Building...error: /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/string.c:499: undefined reference to `_restgpr_30_x' liblibc.a(string.o): In function `strcasecmp': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/string.c:513: undefined reference to `_restgpr_27_x' liblibc.a(string.o): In function `strncasecmp': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/string.c:527: undefined reference to `_restgpr_26_x' liblibc.a(vsprintf.o): In function `number': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/vsprintf.c:145: undefined reference to `_restgpr_17_x' liblibc.a(vsprintf.o): In function `vsnprintf': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/vsprintf.c:388: undefined reference to `_restgpr_21_x' libgcc.a(__divdi3.o): In function `__divdi3': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/__divdi3.c:8: undefined reference to `_savegpr_31' /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/__divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/__udivmoddi4.c:31: undefined reference to `_restgpr_30_x' make[1]: *** [openbios-qemu.elf] Error 1 make: *** [build] Error 1
Anyone else noticed that on another system? Is it a GCC bug or are changes to OpenBIOS code required?
Hmmm this looks like its related to this past thread here: http://lists.openbios.org/pipermail/openbios/2010-January/004464.html. Unfortunately I'm not familiar enough with gcc to know what the solution should be :(
ATB,
Mark.
On 4/23/10 2:21 PM, Andreas Färber wrote:
Hi,
Am 10.04.2010 um 18:26 schrieb Andreas Färber:
Some notes: binutils 2.20.1 and 2.20 do not compile on Mac OS X v10.6. They error about lots of _("...") format strings that Ubuntu (gcc 4.4.1) just warns about. [...]
--disable-werror was able to workaround that much easier than editing the sources, thanks for the hint.
Fixing the warnings would be preferable. Patches appreciated
Anyone else noticed that on another system? Is it a GCC bug or are changes to OpenBIOS code required?
GCC with -Os on PPC32 seems to want this now
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.3...
On 4/23/10, Stefan Reinauer stepan@openbios.org wrote:
On 4/23/10 2:21 PM, Andreas Färber wrote:
Hi,
Am 10.04.2010 um 18:26 schrieb Andreas Färber:
Some notes: binutils 2.20.1 and 2.20 do not compile on Mac OS X v10.6. They error about lots of _("...") format strings that Ubuntu (gcc 4.4.1) just warns about. [...]
--disable-werror was able to workaround that much easier than editing the sources, thanks for the hint.
Fixing the warnings would be preferable. Patches appreciated
Anyone else noticed that on another system? Is it a GCC bug or are changes to OpenBIOS code required?
GCC with -Os on PPC32 seems to want this now
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.3...
Pretty ugly. Perhaps we should try harder to drop our own copy of libgcc?
--disable-werror was able to workaround that much easier than editing the sources, thanks for the hint.
Fixing the warnings would be preferable. Patches appreciated
It is fixed on binutils trunk AFAIK; if you feel you must have your own fork of binutils, you can grab the relevant patch(es) there.
Segher
/Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/ string.c:499: undefined reference to `_restgpr_30_x' liblibc.a(string.o): In function `strcasecmp': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/ string.c:513: undefined reference to `_restgpr_27_x' liblibc.a(string.o): In function `strncasecmp': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/ string.c:527: undefined reference to `_restgpr_26_x' liblibc.a(vsprintf.o): In function `number': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/ vsprintf.c:145: undefined reference to `_restgpr_17_x' liblibc.a(vsprintf.o): In function `vsnprintf': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libc/ vsprintf.c:388: undefined reference to `_restgpr_21_x' libgcc.a(__divdi3.o): In function `__divdi3': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/ __divdi3.c:8: undefined reference to `_savegpr_31' /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/ __divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /Users/andreas/QEMU/OpenBIOS/openbios-devel/obj-ppc/../libgcc/ __udivmoddi4.c:31: undefined reference to `_restgpr_30_x' make[1]: *** [openbios-qemu.elf] Error 1 make: *** [build] Error 1
Anyone else noticed that on another system? Is it a GCC bug or are changes to OpenBIOS code required?
Newer GCC is using a part of the ABI that older GCC did not. This creates better code, and is not a bug. What _is_ arguably a bug is not using the libgcc that comes with the compiler, but something else.
Why can OpenBIOS not use libgcc?
Segher
Segher Boessenkool wrote:
Newer GCC is using a part of the ABI that older GCC did not. This creates better code, and is not a bug. What _is_ arguably a bug is not using the libgcc that comes with the compiler, but something else.
Why can OpenBIOS not use libgcc?
Good question. Blue came up with a patch here: http://lists.openbios.org/pipermail/openbios/2010-January/004475.html but while it worked at compile time, it failed at runtime. If you could fix that, we'd all be very grateful :)
ATB,
Mark.
Newer GCC is using a part of the ABI that older GCC did not. This creates better code, and is not a bug. What _is_ arguably a bug is not using the libgcc that comes with the compiler, but something else. Why can OpenBIOS not use libgcc?
Good question. Blue came up with a patch here: http:// lists.openbios.org/pipermail/openbios/2010-January/004475.html but while it worked at compile time, it failed at runtime. If you could fix that, we'd all be very grateful :)
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. I'll do my best with directed questions of course :-)
Segher
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...
ATB,
Mark.
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.
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
Changing the code model most likely changes the ABI,
It does not, it only restricts what pointer values are legal, it doesn't change calling convention or struct layout or the like.
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.
No, that is a bug, and specific to x86.
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
The mad rush for 4.5 is over, maybe some poking is in order. You do realise this isn't a very high priority bug for most people, right.
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.
No, that is not the party line.
So the simplest way is just not assuming any ABI details if possible and not using CFLAGS that change the default ABI.
Sure, but then you have to build a compiler that defaults to the ABI you want. Note that this anyway doesn't solve the regparm model, and also not the Sparc -mcmodel problem AFAICS.
The "simplest way" to fix it would be first to figure out exactly what is actually wrong, and go from there.
Segher
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.
No, that is not the party line.
Huh? If you use ABI changing options then you need libraries that match. This includes libgcc. In rare cases it may be possible to get limited iteroperation, but this is the exception rather than the rule.
So the simplest way is just not assuming any ABI details if possible and not using CFLAGS that change the default ABI.
Sure, but then you have to build a compiler that defaults to the ABI you want. Note that this anyway doesn't solve the regparm model, and also not the Sparc -mcmodel problem AFAICS.
The "simplest way" to fix it would be first to figure out exactly what is actually wrong, and go from there.
You can't assume that an object/library (in particular libgcc) compiled for one target environment will work on a different target, even if they nominally use the same ABI. For example in a linux userspace environment the correct way to indicate division by zero may be a raise/kill syscall. Obviously this is completely bogus in a bare metal environment.
If you want to use the wrong toolchain (e.g. a linux targeted compiler for bare metal applications such as bootloaders or kernels) then you should expect to have to jump though hoops. The hacks required vary by both architecture and compiler version, and range from making sure you never write particular code sequences to providing your own implementation of all the libgcc routines. This is an internal compiler ABI, so the requirements may change without warning.
Paul
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.
No, that is not the party line.
Huh? If you use ABI changing options then you need libraries that match. This includes libgcc. In rare cases it may be possible to get limited iteroperation, but this is the exception rather than the rule.
Sure, but in that case GCC itself should select a matching multilib, or do whatever else is necessary to make -mregparm useful at all.
See also comment #4 on PR41055.
You can't assume that an object/library (in particular libgcc) compiled for one target environment will work on a different target, even if they nominally use the same ABI.
Sure.
For example in a linux userspace environment the correct way to indicate division by zero may be a raise/kill syscall. Obviously this is completely bogus in a bare metal environment.
Well, in the case at hand, dividing by zero is wrong /per se/, so we should figure out why that happened.
If you want to use the wrong toolchain (e.g. a linux targeted compiler for bare metal applications such as bootloaders or kernels) then you should expect to have to jump though hoops. The hacks required vary by both architecture and compiler version, and range from making sure you never write particular code sequences to providing your own implementation of all the libgcc routines. This is an internal compiler ABI, so the requirements may change without warning.
Building with a powerpc-eabi toolchain should work though, and it doesn't either if I understand correctly.
Segher
On 4/26/10, Stefan Reinauer stepan@openbios.org wrote:
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.
I made another test by removing any -mcmodel flags. That makes Milax not crash, though it doesn't work any better. But then all Linux tests start to crash.
I would suppose that without -mcmodel, gcc and libgcc would always match. The remaining suspects (besides general bugginess of gcc or my hosed configuration) are -m64 (and related as flags) and -fno-builtin.
I made another test by removing any -mcmodel flags. That makes Milax not crash, though it doesn't work any better. But then all Linux tests start to crash.
I would suppose that without -mcmodel, gcc and libgcc would always match. The remaining suspects (besides general bugginess of gcc or my hosed configuration) are -m64 (and related as flags) and -fno-builtin.
You forget what is (in my mind) the prime suspect: the OpenBIOS code itself has a bug.
Anyhow, it's useless to speculate; figure out *what* is going wrong first, then find the root cause of it.
Segher
I think I can now reproduce the crash, previously I had no problems which made debugging a bit difficult.
On sparc64, not PowerPC as we were talking about. Could be the same problem, of course.
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.
Code model on Sparc V9 does not change ABI.
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
Backtrace?
Why this doesn't happen with our libgcc? Why it doesn't happen with -mcmodel=medany? What a puzzle.
My intuition says you are dividing (a value derived from) a pointer by an integer here, does that ring any bells?
One solution could be to check for division by zero in mudivmod(), which is where __umodti3 is called from.
A better solution is not to divide by zero in the first place ;-)
Segher
Blue Swirl wrote:
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.
Earlier today Segher was kind enough to send me some pointers over IRC. One of the things we did find was that the version of gcc may be relevant. My original cross-compiler was based on gcc 4.3.2 and with your attached patch causes a crash - but upgrading to gcc 4.5.0 and then rebuilding OpenBIOS with your patch creates a working runtime once again.
What version of gcc are you using for your cross compilers?
ATB,
Mark.
On 5/1/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
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.
Earlier today Segher was kind enough to send me some pointers over IRC. One of the things we did find was that the version of gcc may be relevant. My original cross-compiler was based on gcc 4.3.2 and with your attached patch causes a crash - but upgrading to gcc 4.5.0 and then rebuilding OpenBIOS with your patch creates a working runtime once again.
What version of gcc are you using for your cross compilers?
Using built-in specs. Target: sparc64-elf Configured with: ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-ssp : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
Using built-in specs. Target: powerpc-elf Configured with: ../configure --target=powerpc-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
Using built-in specs. Target: sparc-elf Configured with: ../configure --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-multilib --enable-languages=c --with-gnu-ld --with-gnu-as --disable-libssp --target=sparc-elf Thread model: single gcc version 4.2.4
On 5/1/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
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.
Earlier today Segher was kind enough to send me some pointers over IRC. One of the things we did find was that the version of gcc may be relevant. My original cross-compiler was based on gcc 4.3.2 and with your attached patch causes a crash - but upgrading to gcc 4.5.0 and then rebuilding OpenBIOS with your patch creates a working runtime once again.
I also built a cross-compiler with gcc 4.5.0. It produces working binaries with current SVN HEAD. The (expected) result with SVN HEAD is that Milax loads but we get back to OpenBIOS prompt, with 'go' OpenSolaris loads but there is an error message about panic buffer. In Linux tests, SILO loads Linux kernel, which then complains about PBM-A space.
But with the libgcc removal patch applied, I get this with Milax: [sparc64] Booting file 'cdrom' with parameters '' Unhandled Exception 0x00000001ffcd2000 PC = 0x00000000ffd2296c NPC = 0x00000000ffd22970 Stopping execution
Linux tests crash before SILO. It's strange that in your tests this worked.
SVN HEAD, only removed all -mcmodel flags: Milax boots but crashes before complaining about panic buffer: Jumping to entry point 00000000010071d8 for type 0000000000000001... switching to new context: entry point 0x10071d8 stack 0x00000000ffe02a91 Unhandled Exception 0x0000000100e66000 PC = 0x00000000ffd1dc10 NPC = 0x00000000ffd1dc14 Stopping execution
The same happens with both libgcc removal and no-mcmodel patches applied. Linux boot tests crash during SILO load.
There was some discussion earlier that instead of sparc64-elf, sparc64-eabi would be a better choice. But I got this error when configuring gcc: *** Configuration sparc64-unknown-eabi not supported
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,
$ du -sh ~/cross/ 4.5G /home/segher/cross/
Yeah, I have a PowerPC cross-compiler.
the build is easy:
./config/scripts/switch-arch cross-ppc make
Then copy the resulting binary from obj-ppc/ into your share/qemu directory.
...but qemu hasn't worked for me for many years. Maybe I should try again, sigh.
Find me on IRC?
Segher
-
Andreas Färber -
Blue Swirl -
Mark Cave-Ayland -
Paul Brook -
Segher Boessenkool -
Stefan Reinauer