On Mon, Nov 1, 2010 at 12:33 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 08.10.2010 um 15:30 schrieb Alexander Graf:
You can use the apple gdb without an object file, so you don't get symbols. But if you have an instruction pointer, just
$ qemu-system-ppc -s -S ... (gdb) target remote localhost:1234 (gdb) b *0x1234 <- address of rtas_something (gdb) c
It should break on that IP and then you can evaluate the register contents at least. Either by
(gdb) info registers
or
(qemu) info registers
I'm trying to find out how far we get with the ppc64 OpenBIOS, so I've tried the following:
$ .../ppc64-softmmu/qemu-system-ppc64 ... -nographic -prom-env 'auto-boot?=false' -s -S
$ gdb --arch=ppc64 GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin". (gdb) target remote localhost:1234 Remote debugging using localhost:1234 [New thread 1] 0x0000000000000000 in ?? () (gdb) b *0xfffffffc Breakpoint 1 at 0xfffffffc (gdb) c Continuing.
It doesn't break though and executes to the OpenBIOS prompt. 0xfffffffc is supposed to be the hard reset vector, i.e. the very first instruction it must execute to branch to _entry.
Any suggestions?
Maybe try to do "stepi" instead of "c" to prove execution starts from 0xfffffffc? Breakpoints are unreliable in qemu. Particularly traps are really hard to debug (at least in the sparc port).