[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments
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:
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
>> 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
>> 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
>> (gdb) file obj-sparc32/openbios-builtin.elf.nostrip
>> Reading symbols from
>> (gdb) target remote :1234
>> Remote debugging using :1234
>> [New Thread 1]
>> 0x00000000 in ?? ()
>> (gdb) cont
>> Program received signal SIGINT, Interrupt.
>> 0x00106190 in ?? ()
>> (gdb) stepi
>> 0x00106194 in ?? ()
>> 0x00106190 in ?? ()
>> (gdb) disas 0x106190 0x106194
>> Dump of assembler code from 0x106190 to 0x106194:
>> 0x00106190: call 0x106190
>> End of assembler dump.
>> 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...
Size: 18942 bytes
Desc: not available
More information about the OpenBIOS