Nick Couchman wrote:
(Sorry if the patch wasn't supposed to fix this...)
After applying this patch still getting:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 claim isn't unique. release isn't unique. Welcome to OpenBIOS v1.0 built on Nov 30 2009 15:44 Type 'help' for detailed information
0 > boot cdrom [sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7120 bytes entry point is 0x4000 Evaluating FCode... Unhandled Exception 0x0000000008000000 PC = 0x00000000ffd10e3c NPC = 0x00000000ffd10e40 Stopping execution
and GDB shows the error at: (gdb) l *0x00000000ffd10e3c 0xffd10e3c is in cfetch (../include/openbios/stack.h:34). 29 typedef ucell phandle_t; 30 31 32 33 34 static inline void PUSH(ucell value) { 35 dstack[++dstackcnt] = (value); 36 } 37 static inline void PUSH_xt( xt_t xt ) { PUSH( (ucell)xt ); } 38 static inline void PUSH_ih( ihandle_t ih ) { PUSH( (ucell)ih ); }
Let me know if I can provide any additional output or debugging steps! -Nick
Well, it got things a bit further but there is still another bug present. In this case the backtrace is useless because it's a Forth issue rather than a C issue - it's often more useful to step through in Forth first to see which word causes the breakage rather than post a backtrace from within the Forth engine.
In this case, I did a little bit of detective work and found that the branch offset calculations are wrong for certain combinations of nested b(<mark) and bbranch. I'm fairly sure I can fix this, I just need to find a moment to come up with a fix and test it. Oh, and I'll apply the above patch too.
ATB,
Mark.