[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:
>
>> ok, 2.6 confirms that there is a problem with 80 characters limit:
>> ...
>>
>> obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192
>> obp_devseek(fd 0xffd9e740, hi 0, lo 15065088) = 0
>> obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192
>> obp_devclose(0xffd9e740) = 1
>> obp_fortheval_v2( ['] find-device catch if 2drop true else
>> current-device device-end then swap l!)
>> Unhandled Exception 0x00000007
>> PC = 0xffd05580 NPC = 0xffd05024
>> Stopping execution
>
> Definitely time for you to build a cross-gdb :)

how to see in the gdb how many items are on a forth stack?

>  I notice a comment in
> obp_fortheval_v2 that reads:
>
>
>  // for now, move something to the stack so we
>  // don't get a stack underrun.
>  //
>  // FIXME: find out why solaris doesnt put its stuff on the stack
>  //
>  fword("0");
>  fword("0");
>
>
> So perhaps the OpenBIOS marshalling code for romvec doesn't handle passing
> Forth stack parameters correctly? Try searching for Sun romvec documentation
> to see what you can find about how parameters are passed to/from the BIOS.

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:

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.

-- 
Regards,
Artyom Tarasenko

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