At 8:07 PM +0200 4/22/05, R=E9mi Zara wrote:
>
>Ok, I will have to try to understand all that...
>
>> At the exception, try
>>
>> %LR 10 dis
>
>0 > %LR 10 dis

Well, I screwed that one up.  It should read:

%LR 10 - dis


The error was a result of changing from dump to dis.  My fault.

>
>
>> That'll give you the four instructions before and something like eight
>> after the bl or blrl instruction.  From there you can objdump -d the
>> kernel
>> and locate the same instructions.  That'll narrow down where the jump
>> off
>> occured.
>
>Well, the kernel is cross compiled from MacOSX 10.3, so I'm not sur I
>can easily do that....

Eeep.  All bets are off.  I think OS X's objdump can still yield the
location, but I don't know that I'd trust its building abilities.  I would
think it would make comparing kernels built on NetBSD unreliable.

>> If dis craps out, as it often does on early OF, try
>>
>> %LR 10 - 20 dump
>
>Since I don't know what it's supposed to look like...
>
>1 > %LR 10 - 20 dump
>0035724C: 90 81 D8 18 91 01 00 14 7D 69 03 A6 4E 80 04 21
>0035725C: 80 01 00 24 38 21 00 20 7C F6 D9 C4 4E 80 00 20 ok

9081D818
91010014
7D6903A6
4E800421
80010024
38210020
7CF6D9C4
4E800020

stw        r4,-0x27E8(SP)              | 9081D818
stw        r8,0x0014(SP)               | 91010014
mtctr      r11       ; CTR =3D 0x0009 | 7D6903A6
bctrl                                              | 4E800421
lwz        r0,0x0024(SP)                | 80010024
addi       SP,SP,0x0020                 | 38210020
dc.l       0x7CF6D9C4                    | 7CF6D9C4
blr                                                | 4E800020


The %LR was at 0035725C, which is four instructions from the dump location.
The bctrl (branch to count register and load instruction to link register)
is the jump off point, and the lwz contains the instruction a return via
the link register would execute next. The CTR was loaded from r11, which
was 57000558 in your original post.  The dc.l is an opcode my disassembler
doesn't recognize.  Between that and the stw instruction at the start of
the dump, you should be able to identify a fairly unique set of
instructions.  objdump -d the kernel, find 0035725C, compare it to what is
in memory, and identify the subroutine it is in.  If the code matches what
is in memory, then it's not a corrupted kernel image and the next step is
to identify how r11 comes to be the value that it is.

I'm fifty-fifty on the integrity/viability of the kernel.  The blr needs
the previous opcode to load the link register.  If my disassembler (MacsBug
on a G4) doesn't know that opcode, I believe it to be highly unlikely to
execute on a 601 chip.  Perhaps the jumpoff point overrides the LR and
skips this code.

tim :-)