[OpenBIOS] [Qemu-ppc] MorphOS 4.x on QEMU

[Mark Cave-Ayland]

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.