On Sun, Oct 24, 2010 at 1:24 AM, Mark Cave-Ayland mark.cave-ayland@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@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.