[OpenBIOS] OpenSolaris starts to live on SPARC64

[Artyom Tarasenko]

2010/4/6 Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>:
> Artyom Tarasenko wrote:
>
>> how to see in the gdb how many items are on a forth stack?
>
> See include/kernel/stack.h for the Forth stack operations. rstack and dstack
> are the return and data arrays stacks respectively, while rstackcnt and
> dstackcnt point to the topmost stack item. So the current item at the top of
> the stack is viewable with:
>
> print dstack[dstackcnt]
>
> Also make sure you alter obj-sparc32/Makefile so that CFLAGS uses -O0 rather
> than -Os - otherwise the optimiser will be quite aggressive and lose debug
> information.
>
>> Yep, found that too. Actually I was wrong: replacing second space with
>> 0x0a
>> doesn't bring it further. Don't know why it did before. Probably I messed
>> up the
>> binary.  So, obp_fortheval_v2 is broken regardless of the line length:
>
> Okay. That's useful to know.
>
>> obp_getprop(0xffd72f88, reg) = 00 00 00 05 08 80 00 00 00 00 00 10
>> obp_fortheval_v2( ['] find-device
>> catch if 2drop true else current-device device-end then swap l!)
>> Unhandled Exception 0x00000007
>> PC = 0xffd05f44 NPC = 0xffd05f48
>>
>>>> 2.5.1 :
>>>>
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00a0778, nbytes 8192) = 8192
>>>> obp_devseek(fd 0xffd9eb94, hi 0, lo 275275776) = 0
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00a2778, nbytes 8192) = 8192
>>>> obp_devseek(fd 0xffd9eb94, hi 0, lo 275283968) = 0
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00a4778, nbytes 8192) = 8192
>>>> obp_devseek(fd 0xffd9eb94, hi 0, lo 275292160) = 0
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00a6778, nbytes 8192) = 8192
>>>> obp_devseek(fd 0xffd9eb94, hi 0, lo 275316736) = 0
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00a8778, nbytes 8192) = 8192
>>>> obp_devseek(fd 0xffd9eb94, hi 0, lo 275324928) = 0
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00aa778, nbytes 8192) = 8192
>>>> obp_devseek(fd 0xffd9eb94, hi 0, lo 275333120) = 0
>>>> obp_devread(fd 0xffd9eb94, buf 0xf00ac778, nbytes 8192) = 8192
>>>>
>>>> And then it just hangs. I don't see the "krtld: error during initial
>>>> load/link phase" message.
>>>
>>> Again, you'll need a cross-gdb to check this. At least you can then break
>>> into OpenBIOS and find out at which point you're getting stuck in a loop.
>>
>> debugging a program which behaves differently with debugging switched on
>> and off is no fun. I can try though. What would you suggest as a
>> breakpoint?
>> obp_devread is not the best candidate as it's called like a thousand
>> times.
>
> If the above trace is accurate I'd probably add something like the following
> to obp_devread:
>
> if (fd == 0xffd9eb94 && buf == 0xf00ac778 && nbytes == 8192) {
>        printk("Debug here!\n");
> }
>
> And then use gdb to place a breakpoint on the specific line above containing
> the printk statement.

Got me. I spent too much time debugging stuff without the source. :)

qemu+gdb seem to be unstable though: sometimes qemu crash, and here it
just hangs:

(gdb) break ../arch/sparc32/romvec.c:324
(gdb) target remote :1234
Remote debugging using :1234
0x00000000 in ?? ()
(gdb) cont
Continuing.

Breakpoint 1, obp_devread (dev_desc=<value optimized out>,
    buf=0xffd36138
"\377\326,L\377\326*\364\377\325\365@\377\326D\250\377\326Ix\377\331\316\200\377\331\317\024",
    nbytes=1508192) at ../arch/sparc32/romvec.c:324
324                printk("Debug here!\n");
(gdb) step

<hangs>

stepi and cont do the same. Which gdb version do you use? Mine is 7.1.

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/