[OpenBIOS] OpenSolaris starts to live on SPARC64

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Tue Apr 6 12:09:48 CEST 2010


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.


HTH,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs



More information about the OpenBIOS mailing list