Cross-compiling and testing sparc64 on Mac OS X
Hello guys, It's awesome seeing you've made some progress towards emulating Solaris/sparc64! However trying myself, compiling on Mac OS X (after making sure that NEED_INT128_T is defined) fails with the following error: HOSTCC host/kernel/bootstrap.o In file included from ../include/openbios/sysinclude.h:7, from ../kernel/bootstrap.c:9: /usr/include/stdlib.h:267: error: syntax error before ‘arc4random’ make[1]: *** [host/kernel/bootstrap.o] Error 1 The return type of arc4random is u_int32_t, which is defined (in my case) in <ppc/types.h>. Not sure what goes wrong there. I thought it could be a name clash with OpenBIOS' __TYPES_H (malc would be furious!), but - luckily - Apple uses __TYPES_H_ for their _types.h. Anyway, not having these functions declared by defining _POSIX_C_SOURCE made the compilation proceed with only one warning: HOSTCC host/kernel/bootstrap.o ../kernel/bootstrap.c: In function ‘interpret_source’: ../kernel/bootstrap.c:529: warning: implicit declaration of function ‘strcasecmp’ If I symlink .../share/qemu/openbios-sparc64 to .../obj-sparc64/ openbios-builtin.elf (or copy it over) I get this at runtime: qemu: fatal: Trap 0x0010 while trap level (5) >= MAXTL (5), Error state pc: 0000000000004200 npc: 0000000000004204 General Registers: %g0: 0000000000000000 %g1: 0000000000000000 %g2: 0000000008000000 %g3: 0000000000000000 %g4: 0000000000000000 %g5: 0000000000000000 %g6: 0000000000000000 %g7: 0000000000000000 Current Register Window: %o0: 00000000ffe00000 %o1: 00000000ffe01000 %o2: 000001fff0100000 %o3: 000001fff0000000 %o4: 0000000000000000 %o5: 0000000000000000 %o6: 0000000000000000 %o7: 000001ff00000000 %l0: 0000000007e80000 %l1: 000001ff00000000 %l2: 000001fff0080000 %l3: 0000000000000000 %l4: 0000000000000000 %l5: 0000000000000000 %l6: 0000000000000000 %l7: 0000000000000000 %i0: 0000000000000000 %i1: 0000000000000000 %i2: 0000000000000000 %i3: 0000000000000000 %i4: 0000000000000000 %i5: 0000000000000000 %i6: 0000000000000000 %i7: 0000000000000000 Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 0x00000015 ccr: 0x99 asi: 0x00 tl: 5 fprs: 0 cansave: 6 canrestore: 0 otherwin: 0 wstate 0 cleanwin 6 cwp 7 fsr: 0x00000000 ../qemu-solaris-sparc.command: line 3: 3289 Abort trap / Users/andreas/Q/latest/bin/qemu-system-sparc64 -nographic -boot d - cdrom /Users/andreas/Q/sol-10-u3-ga-sparc-dvd.iso This looks different from what you've posted and is identical with QEMU's version of openbios-sparc64. Same with or without -nographic. Any ideas? Regards, Andreas
Andreas Färber wrote:
Hello guys,
It's awesome seeing you've made some progress towards emulating Solaris/sparc64!
However trying myself, compiling on Mac OS X (after making sure that NEED_INT128_T is defined) fails with the following error:
HOSTCC host/kernel/bootstrap.o In file included from ../include/openbios/sysinclude.h:7, from ../kernel/bootstrap.c:9: /usr/include/stdlib.h:267: error: syntax error before ‘arc4random’ make[1]: *** [host/kernel/bootstrap.o] Error 1
The return type of arc4random is u_int32_t, which is defined (in my case) in <ppc/types.h>. Not sure what goes wrong there. I thought it could be a name clash with OpenBIOS' __TYPES_H (malc would be furious!), but - luckily - Apple uses __TYPES_H_ for their _types.h. Anyway, not having these functions declared by defining _POSIX_C_SOURCE made the compilation proceed with only one warning:
HOSTCC host/kernel/bootstrap.o ../kernel/bootstrap.c: In function ‘interpret_source’: ../kernel/bootstrap.c:529: warning: implicit declaration of function ‘strcasecmp’
If I symlink .../share/qemu/openbios-sparc64 to .../obj-sparc64/openbios-builtin.elf (or copy it over) I get this at runtime:
qemu: fatal: Trap 0x0010 while trap level (5) >= MAXTL (5), Error state pc: 0000000000004200 npc: 0000000000004204 General Registers: %g0: 0000000000000000 %g1: 0000000000000000 %g2: 0000000008000000 %g3: 0000000000000000 %g4: 0000000000000000 %g5: 0000000000000000 %g6: 0000000000000000 %g7: 0000000000000000 Current Register Window: %o0: 00000000ffe00000 %o1: 00000000ffe01000 %o2: 000001fff0100000 %o3: 000001fff0000000 %o4: 0000000000000000 %o5: 0000000000000000 %o6: 0000000000000000 %o7: 000001ff00000000 %l0: 0000000007e80000 %l1: 000001ff00000000 %l2: 000001fff0080000 %l3: 0000000000000000 %l4: 0000000000000000 %l5: 0000000000000000 %l6: 0000000000000000 %l7: 0000000000000000 %i0: 0000000000000000 %i1: 0000000000000000 %i2: 0000000000000000 %i3: 0000000000000000 %i4: 0000000000000000 %i5: 0000000000000000 %i6: 0000000000000000 %i7: 0000000000000000
Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 0x00000015 ccr: 0x99 asi: 0x00 tl: 5 fprs: 0 cansave: 6 canrestore: 0 otherwin: 0 wstate 0 cleanwin 6 cwp 7 fsr: 0x00000000 ../qemu-solaris-sparc.command: line 3: 3289 Abort trap /Users/andreas/Q/latest/bin/qemu-system-sparc64 -nographic -boot d -cdrom /Users/andreas/Q/sol-10-u3-ga-sparc-dvd.iso
This looks different from what you've posted and is identical with QEMU's version of openbios-sparc64. Same with or without -nographic.
Any ideas?
Hmmm that's a tricky one. Does it not even get to the OpenBIOS prompt? You need to be using a recent git master for Qemu as well as OpenBIOS SVN, although I haven't updated my local copy for a couple of weeks. Can you try launching a PPC Qemu instance with both the supplied openbios-ppc and then building your own to confirm that they both display the same behaviour? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Hello Mark, Am 29.11.2009 um 14:43 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
qemu: fatal: Trap 0x0010 while trap level (5) >= MAXTL (5), Error state pc: 0000000000004200 npc: 0000000000004204 General Registers: %g0: 0000000000000000 %g1: 0000000000000000 %g2: 0000000008000000 %g3: 0000000000000000 %g4: 0000000000000000 %g5: 0000000000000000 %g6: 0000000000000000 %g7: 0000000000000000 Current Register Window: %o0: 00000000ffe00000 %o1: 00000000ffe01000 %o2: 000001fff0100000 %o3: 000001fff0000000 %o4: 0000000000000000 %o5: 0000000000000000 %o6: 0000000000000000 %o7: 000001ff00000000 %l0: 0000000007e80000 %l1: 000001ff00000000 %l2: 000001fff0080000 %l3: 0000000000000000 %l4: 0000000000000000 %l5: 0000000000000000 %l6: 0000000000000000 %l7: 0000000000000000 %i0: 0000000000000000 %i1: 0000000000000000 %i2: 0000000000000000 %i3: 0000000000000000 %i4: 0000000000000000 %i5: 0000000000000000 %i6: 0000000000000000 %i7: 0000000000000000 Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 0x00000015 ccr: 0x99 asi: 0x00 tl: 5 fprs: 0 cansave: 6 canrestore: 0 otherwin: 0 wstate 0 cleanwin 6 cwp 7 fsr: 0x00000000 ../qemu-solaris-sparc.command: line 3: 3289 Abort trap /Users/andreas/Q/latest/bin/qemu-system-sparc64 - nographic -boot d -cdrom /Users/andreas/Q/sol-10-u3-ga-sparc-dvd.iso This looks different from what you've posted and is identical with QEMU's version of openbios-sparc64. Same with or without -nographic. Any ideas?
Hmmm that's a tricky one. Does it not even get to the OpenBIOS prompt?
Nope. Not ruling out a QEMU issue, but it's specific to sparc64 on Mac OS X host. I never got further on sparc64, so the errors you are discussing now seemed like a leap forward. ;) On Linux/amd64 I do get the OpenBIOS prompt with either 'open is not unique' or 'byte-load exception' (testing Solaris 10 U3, Solaris Nevada b127 and MilaX 0.3.2).
You need to be using a recent git master for Qemu as well as OpenBIOS SVN [...]
I'm at OpenBIOS trunk HEAD (r635) and was at QEMU master 63e86b2e13396310feff1fe1a5988b5742487636.
Can you try launching a PPC Qemu instance with both the supplied openbios-ppc and then building your own to confirm that they both display the same behaviour?
With ppc or sparc32 emulation I do not have this issue. Debian/sparc32 boots fine 'til login and Debian/ppc has some graphic glitches (penguin miscolored on OSX/Cocoa, missing on Linux/SDL) but gets to the first installation screen. Andreas
Andreas Färber wrote:
Nope. Not ruling out a QEMU issue, but it's specific to sparc64 on Mac OS X host. I never got further on sparc64, so the errors you are discussing now seemed like a leap forward. ;)
On Linux/amd64 I do get the OpenBIOS prompt with either 'open is not unique' or 'byte-load exception' (testing Solaris 10 U3, Solaris Nevada b127 and MilaX 0.3.2).
Right. So if you copy the openbios binary you built under Linux/amd64 to your OS X host, does it work? This will tell you whether it's an OpenBIOS build problem or a Qemu on OS X problem. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Am 29.11.2009 um 17:12 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
Nope. Not ruling out a QEMU issue, but it's specific to sparc64 on Mac OS X host. I never got further on sparc64, so the errors you are discussing now seemed like a leap forward. ;) On Linux/amd64 I do get the OpenBIOS prompt with either 'open is not unique' or 'byte-load exception' (testing Solaris 10 U3, Solaris Nevada b127 and MilaX 0.3.2).
Right. So if you copy the openbios binary you built under Linux/ amd64 to your OS X host, does it work? This will tell you whether it's an OpenBIOS build problem or a Qemu on OS X problem.
It's probably not an OpenBIOS build problem. I was able to execute an OSX-built OpenBIOS on Linux and OpenSolaris. Executing a Linux-built OpenBIOS on OSX/ppc failed. Using same GCC 4.4.2 and binutils 2.20. That still leaves OS differences, the endianness, the bitness, etc. etc. Maybe Blue has a hunch? Andreas
Am 29.11.2009 um 19:32 schrieb Andreas Färber:
Am 29.11.2009 um 17:12 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
Not ruling out a QEMU issue, but it's specific to sparc64 on Mac OS X host. I never got further on sparc64, so the errors you are discussing now seemed like a leap forward. ;) On Linux/amd64 I do get the OpenBIOS prompt with either 'open is not unique' or 'byte-load exception' (testing Solaris 10 U3, Solaris Nevada b127 and MilaX 0.3.2).
Right. So if you copy the openbios binary you built under Linux/ amd64 to your OS X host, does it work? This will tell you whether it's an OpenBIOS build problem or a Qemu on OS X problem.
It's probably not an OpenBIOS build problem. I was able to execute an OSX-built OpenBIOS on Linux and OpenSolaris. Executing a Linux- built OpenBIOS on OSX/ppc failed. Using same GCC 4.4.2 and binutils 2.20.
I've just checked on OSX/i386, and both stock and custom openbios- sparc64 boot without the reported crash. So it's likely not a 32-bit issue and it's not Mac OS X per se... This is what I got booting Debian GNU/Linux 4.0r3 with -nographic btw: [...] Remapping the kernel... done. Booting Linux... Inconsistent console: input 5, output 5 EXIT 11a> Without -nographic it hangs after "Remapping the kernel... done.", making the fan spin louder and not dropping back to the OpenBIOS prompt. Andreas
On Sun, Nov 29, 2009 at 8:32 PM, Andreas Färber <andreas.faerber@web.de> wrote:
Am 29.11.2009 um 17:12 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
Nope. Not ruling out a QEMU issue, but it's specific to sparc64 on Mac OS X host. I never got further on sparc64, so the errors you are discussing now seemed like a leap forward. ;) On Linux/amd64 I do get the OpenBIOS prompt with either 'open is not unique' or 'byte-load exception' (testing Solaris 10 U3, Solaris Nevada b127 and MilaX 0.3.2).
Right. So if you copy the openbios binary you built under Linux/amd64 to your OS X host, does it work? This will tell you whether it's an OpenBIOS build problem or a Qemu on OS X problem.
It's probably not an OpenBIOS build problem. I was able to execute an OSX-built OpenBIOS on Linux and OpenSolaris. Executing a Linux-built OpenBIOS on OSX/ppc failed. Using same GCC 4.4.2 and binutils 2.20. That still leaves OS differences, the endianness, the bitness, etc. etc. Maybe Blue has a hunch?
What about x86_64 target or other 64 bit targets, do you have problems with those?
Hey, Am 30.11.2009 um 22:03 schrieb Blue Swirl:
What about x86_64 target or other 64 bit targets, do you have problems with those?
Hadn't checked yet. Booting Fedora 12 DVD results in immediate segfault! (gdb) run -boot d -cdrom ../Fedora-12-x86_64-DVD.iso -nographic Starting program: /Users/andreas/QEMU/latest/bin/qemu-system-x86_64 - boot d -cdrom ../Fedora-12-x86_64-DVD.iso -nographic Reading symbols for shared libraries +++++++++++++++ +............................................................... done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries .. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 __stl_mmu (addr=0, val=0, mmu_idx=-1) at /Users/andreas/QEMU/qemu/target-i386/op_helper.c:259 259 return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24); (gdb) bt #0 __stl_mmu (addr=0, val=0, mmu_idx=-1) at /Users/andreas/ QEMU/qemu/target-i386/op_helper.c:259 #1 0x06000500 in ?? () #2 0x000dbcd0 in cpu_x86_exec (env1=<value temporarily unavailable, due to optimizations>) at /Users/andreas/QEMU/qemu/target-i386/ op_helper.c:259 #3 0x0000a5b8 in qemu_main (argc=6, argv=0xbffff7e4, envp=<value temporarily unavailable, due to optimizations>) at /Users/andreas/QEMU/ qemu/target-i386/op_helper.c:259 #4 0x000c9268 in -[QemuCocoaAppController startEmulationWithArgc:argv:] (self=<value temporarily unavailable, due to optimizations>, _cmd=<value temporarily unavailable, due to optimizations>, argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at /Users/andreas/QEMU/qemu/target-i386/op_helper.c:259 #5 0x93765688 in _nsnote_callback () #6 0x94c0643c in _CFXNotificationPostNotification () #7 0x93762dc4 in -[NSNotificationCenter postNotificationName:object:userInfo:] () #8 0x940f1858 in -[NSApplication _postDidFinishNotification] () #9 0x940f1770 in -[NSApplication _sendFinishLaunchingNotification] () #10 0x94079114 in -[NSApplication(NSAppleEventHandling) _handleAEOpen:] () #11 0x9407894c in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] () #12 0x93786008 in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] () #13 0x93785ddc in _NSAppleEventManagerGenericHandler () #14 0x93498ce4 in aeDispatchAppleEvent () #15 0x93498bec in dispatchEventAndSendReply () #16 0x934989f0 in aeProcessAppleEvent () #17 0x95579410 in AEProcessAppleEvent () #18 0x94076478 in _DPSNextEvent () #19 0x94075c00 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #20 0x9406f8a0 in - [NSApplication run] () #21 0x000c9a8c in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at /Users/andreas/QEMU/qemu/target-i386/op_helper.c:259 Current language: auto; currently c (gdb) Andreas
On Fri, Nov 27, 2009 at 1:49 AM, Andreas Färber <andreas.faerber@web.de> wrote:
Hello guys,
It's awesome seeing you've made some progress towards emulating Solaris/sparc64!
However trying myself, compiling on Mac OS X (after making sure that NEED_INT128_T is defined) fails with the following error:
HOSTCC host/kernel/bootstrap.o In file included from ../include/openbios/sysinclude.h:7, from ../kernel/bootstrap.c:9: /usr/include/stdlib.h:267: error: syntax error before ‘arc4random’ make[1]: *** [host/kernel/bootstrap.o] Error 1
The return type of arc4random is u_int32_t, which is defined (in my case) in <ppc/types.h>. Not sure what goes wrong there. I thought it could be a name clash with OpenBIOS' __TYPES_H (malc would be furious!), but - luckily - Apple uses __TYPES_H_ for their _types.h. Anyway, not having these functions declared by defining _POSIX_C_SOURCE made the compilation proceed with only one warning:
HOSTCC host/kernel/bootstrap.o ../kernel/bootstrap.c: In function ‘interpret_source’: ../kernel/bootstrap.c:529: warning: implicit declaration of function ‘strcasecmp’
If I symlink .../share/qemu/openbios-sparc64 to .../obj-sparc64/openbios-builtin.elf (or copy it over) I get this at runtime:
qemu: fatal: Trap 0x0010 while trap level (5) >= MAXTL (5), Error state pc: 0000000000004200 npc: 0000000000004204 General Registers: %g0: 0000000000000000 %g1: 0000000000000000 %g2: 0000000008000000 %g3: 0000000000000000 %g4: 0000000000000000 %g5: 0000000000000000 %g6: 0000000000000000 %g7: 0000000000000000 Current Register Window: %o0: 00000000ffe00000 %o1: 00000000ffe01000 %o2: 000001fff0100000 %o3: 000001fff0000000 %o4: 0000000000000000 %o5: 0000000000000000 %o6: 0000000000000000 %o7: 000001ff00000000 %l0: 0000000007e80000 %l1: 000001ff00000000 %l2: 000001fff0080000 %l3: 0000000000000000 %l4: 0000000000000000 %l5: 0000000000000000 %l6: 0000000000000000 %l7: 0000000000000000 %i0: 0000000000000000 %i1: 0000000000000000 %i2: 0000000000000000 %i3: 0000000000000000 %i4: 0000000000000000 %i5: 0000000000000000 %i6: 0000000000000000 %i7: 0000000000000000
Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 0x00000015 ccr: 0x99 asi: 0x00 tl: 5 fprs: 0 cansave: 6 canrestore: 0 otherwin: 0 wstate 0 cleanwin 6 cwp 7 fsr: 0x00000000 ../qemu-solaris-sparc.command: line 3: 3289 Abort trap /Users/andreas/Q/latest/bin/qemu-system-sparc64 -nographic -boot d -cdrom /Users/andreas/Q/sol-10-u3-ga-sparc-dvd.iso
This looks different from what you've posted and is identical with QEMU's version of openbios-sparc64. Same with or without -nographic.
Any ideas?
Please start QEMU with -d in_asm,out_asm and post the last 100 lines (or so) of /tmp/qemu.log. I'd suspect a bug in Sparc64 emulation, or PPC code generator.
Am 30.11.2009 um 22:01 schrieb Blue Swirl:
Please start QEMU with -d in_asm,out_asm and post the last 100 lines (or so) of /tmp/qemu.log.
I'd suspect a bug in Sparc64 emulation, or PPC code generator.
Attached is the output of `tail -n 100 < /tmp/qemu.log` for MilaX 0.3.2. In light of x86_64 and ppc64 bus errors I'd suspect the ppc TCG target? Thanks, Andreas
Hi, Am 30.11.2009 um 23:23 schrieb Andreas Färber:
Am 30.11.2009 um 22:01 schrieb Blue Swirl:
Please start QEMU with -d in_asm,out_asm and post the last 100 lines (or so) of /tmp/qemu.log.
I'd suspect a bug in Sparc64 emulation, or PPC code generator.
I've ported the ppc64 TCG backend to OSX and found that both sparc64 and x64 work there. It's still odd, but thanks for the TCG hint! Andreas
participants (3)
-
Andreas Färber -
Blue Swirl -
Mark Cave-Ayland