[OpenBIOS] ppc(64) debugging (was: Q: How to "squeeze" C functions in between two symbols?)

[Alexander Graf]

On 31.10.2010, at 17:19, Andreas Färber wrote:

> Am 01.11.2010 um 00:53 schrieb Alexander Graf:
> 
>> On 31.10.2010, at 16:33, Andreas Färber 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.
>> 
>> Uuuh IIRC there's a register that's set on RESET which defines an offset to take when in real mode code or so. Please check the cpu init code for 970, it should tell you :)
> 
> Hm, not sure what init code that would be...

That's the one I meant:

    env->hreset_excp_prefix = 0x00000000FFF00000ULL;
    /* Hardware reset vector */
    env->hreset_vector = 0x0000000000000100ULL;

So it starts at 0x100, not -4 :). Not sure if it's start at 0xfff00100, I'd have to double-check all the code paths.


> Found that the following works slightly better:
> 
> (gdb) x/i 0xfffffffc
> 0xfffffffc:	bl      0xfff02378
> (gdb) b *0xfff02378
> Breakpoint 1 at 0xfff02378
> (gdb) c
> Continuing.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000000000000000 in ?? ()
> (gdb)
> 
> So it seems it's getting there. :)
> All registers including pc are zero though according to info registers, x/10i $pc just shows .long 0x0, and stepi, step, next all don't seem to work. (What worked was disable 1 followed by cont.) Is this something with the host gdb or is something wrong in QEMU, or is the problem in front of the keyboard?

What does info registers in the qemu monitor say?


Alex