[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Sun Oct 24 03:24:56 CEST 2010

Blue Swirl wrote:

> The address of jmp target needs be in a register. Alternatively 'b' should work.

Ah okay. Note for next time I guess :)

> The offsets to %sp are too low, the area you are using is used by
> window trap handlers. They should be %sp+0x60 etc, but usually the
> addressing is %fp-0x20 etc which should yield the same address. Maybe
> this was the problem?
> This document describes the usual stack frame layout:
> http://www.sparc.com/standards/psABI3rd.pdf

Yes indeed! Changing the offsets so that the globals are stored starting 
from %sp + 0x60 solves the problem compiling with -O0 :)

> Other nitpicks: The usual practice is to use 'ret' followed by
> 'restore' in the delay slot (which can also perform 'mov %o0, %i0').
> 'extern' is not needed with function declarations.
> obp_fortheval_v2_handler2() is not used AFAICT. init_openprom()
> declaration should be moved to romvec.h so all romvec stuff is in one
> place.


>> build at zeno:~/src/openbios/openbios-devel$ sparc64-linux-gdb
>> GNU gdb 6.8
>> Copyright (C) 2008 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "--host=x86_64-unknown-linux-gnu
>> --target=sparc64-linux".
>> (gdb) file obj-sparc32/openbios-builtin.elf.nostrip
>> Reading symbols from
>> /home/build/src/openbios/openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip...done.
>> (gdb) target remote :1234
>> Remote debugging using :1234
>> [New Thread 1]
>> 0x00000000 in ?? ()
>> (gdb) cont
>> Continuing.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x00106190 in ?? ()
>> (gdb) stepi
>> 0x00106194 in ?? ()
>> (gdb)
>> 0x00106190 in ?? ()
>> (gdb) disas 0x106190 0x106194
>> Dump of assembler code from 0x106190 to 0x106194:
>> 0x00106190:     call  0x106190
>> End of assembler dump.
>> (gdb)
>> From the addresses and the twirly baton beforehand, I'd say we're actually
>> now in the Solaris kernel. The interesting part of this is the fact that we
>> get stuck in an infinite loop as shown above - I wonder if this is just the
>> Solaris way of handling errors? Or perhaps maybe OpenBIOS doesn't have a
>> romvec entry to enable diagnostic messages to be output to the console?
> We don't implement pv_putstr (not used by Linux) and pv_printf calls
> printk directly without your wrappers.

Hmmmm. I've also added in an implementation of pv_putstr but still don't 
see anything useful output on the console (and in fact, if I set a 
breakpoint on obp_putstr it never breaks which means it isn't being 
called here either). I guess there will have to be some long nights 
tracing through disassembled code :(

Based upon all your comments above, would you say that the attached 
patch is ready for commit? It passes my tests here against my NetBSD, 
Debian and Solaris 8 ISO images.



Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbios-sparc32-romvec-v3.patch
Type: text/x-diff
Size: 18942 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20101024/cd404733/attachment-0001.bin>

More information about the OpenBIOS mailing list