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

[Mark Cave-Ayland]

Blue Swirl wrote:

>> The only thing I can think of is that this simple example fails because of
>> something related to the return address, but I'm not 100% sure.
> 
> 'call' instruction writes the return address to %o7, clobbering
> previous %o7 from the OS. That's why 'save' and 'restore' are needed.
> 
> In this case, alternatively changing just 'call' to 'jmp' and deleting
> the rest should also work.
> 
>> Also what
>> are the rules about how much information you can push onto the stack of the
>> previous frame, i.e. the frame pointer? My current thoughts are that I can
>> either i) push arguments onto the %fp and not save into a new window or ii)
>> push arguments onto the %sp after a save (in which case I need additional
>> code to copy the i registers into the o registers before calling the C
>> function). Does this sound correct?
> 
> I'd go for ii) or 'jmp'.

Okay. I tried using jmp but I got an "out of range" error on compilation 
so I started working on something based on disassembling the output of a 
GCC wrapper function. The attached patch works well my Solaris 8 ISO, 
although now after some twirly batons we appear to be sat in an infinite 
loop:


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?

While there is no notable regression when building with -Os, my NetBSD 
and Debian test ISO images crash out when compiled with -O0 (as set in 
this patch) - anyone have any ideas on this one?


ATB,

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbios-sparc32-romvec-v2.patch
Type: text/x-diff
Size: 18577 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20101023/c31ce480/attachment.bin>