On 04/03/14 18:27, BALATON Zoltan wrote:
On Tue, 4 Mar 2014, BALATON Zoltan wrote:
Raise exception at 00441bcc => 00000002 (00) IN: 0x00000300: b 0xffffc3a0
invalid/unsupported opcode: 00 - 00 - 00 (00000000) ffffc3a0 0 IN: 0xffffc3a0: .long 0x0
Raise exception at ffffc3a4 => 00000006 (21) IN: 0x00000700: mtsprg 2,r2 0x00000704: li r2,7 0x00000708: b 0xffffe0f0
invalid/unsupported opcode: 00 - 00 - 00 (00000000) ffffe0f0 0 IN: 0xffffe0f0: .long 0x0
Raise exception at ffffe0f4 => 00000006 (21) Raise exception at ffffe0f4 => 00000006 (21)
Something seems to overwrite the vector at 0x300 (which was set to 0x238c before this point) but the new value seems to point to the wrong place.
It seems that this is happening when MorphOS tries to install its own exception handlers but something is going wrong during this. What I think it does is copying a block of memory with the exception handler vectors and then it tries to fix up the jumps in it to point to somewhere but either the fixup is not correct or the handlers are not where they are expected to be. I'm currently out of ideas how to debug this further.
Yeah, it's quite tricky without source :/
One trick I managed with the Solaris kernel was to copy the binary (an ELF executable) from the ISO and then load up QEMU with the gdbstub, e.g. with -s -S and use a cross-gdb against the ELF image.
Because the image still had symbols I could extract them using objdump and then set breakpoints at different symbol names to see how far I was getting; plus if I got stuck in a loop then I could often get a clue by using "bt" in gdb to get the call stack and use the symbol names to guess what was happening.
Probably the easiest way though is to try and engage with the MorphOS people on their mailing list and see if someone is willing to give you pointers based on execution addresses (or function names if objdump works) as to what could be the problem.
ATB,
Mark.