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

[Blue Swirl]

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
>> 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.
>
> Done.
>
>>> 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 :(

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.