[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments
blauwirbel at gmail.com
Sun Oct 24 16:08:10 CEST 2010
On Sun, Oct 24, 2010 at 1:24 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Blue Swirl wrote:
>> The address of jmp target needs be in a register. Alternatively 'b' should
> 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
>>> 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
>>> now in the Solaris kernel. The interesting part of this is the fact that
>>> get stuck in an infinite loop as shown above - I wonder if this is just
>>> 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 :(
What about pv_printf?
> 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.
Works for me too.
More information about the OpenBIOS