[OpenBIOS] ppc(64) debugging (was: Q: How to "squeeze" C functions in between two symbols?)
Andreas Färber
andreas.faerber at web.de
Mon Nov 1 03:43:13 CET 2010
Am 01.11.2010 um 01:25 schrieb 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,
Bingo. b *0xfff00100 makes it stop at the breakpoint.
>> 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?
Looking better:
(qemu) info registers
NIP 00000000fff00100 LR 0000000000000000 CTR 0000000000000000 XER
0000000000000000
MSR 8000000000000000 HID0 0000000060000000 HF 8000000000000000 idx 1
TB 00000000 00970400 DECR 4293996894
GPR00 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR04 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR08 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR12 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR24 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR28 0000000000000000 0000000000000000 0000000000000000
0000000000000000
CR 00000000 [ - - - - - - - - ] RES
ffffffffffffffff
FPR00 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPSCR 00000000
SRR0 0000000000000000 SRR1 0000000000000000 SDR1 0000000000000000
(qemu)
But:
(gdb) stepi
0x0000000000000000 in ?? ()
(gdb)
(qemu) info registers
NIP 00000000fff00100 LR 0000000000000000 CTR 0000000000000000 XER
0000000000000000
MSR 8000000000000000 HID0 0000000060000000 HF 8000000000000000 idx 1
TB 00000000 00876800 DECR 4294090494
GPR00 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR04 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR08 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR12 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR24 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR28 0000000000000000 0000000000000000 0000000000000000
0000000000000000
CR 00000000 [ - - - - - - - - ] RES
ffffffffffffffff
FPR00 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000
0000000000000000
FPSCR 00000000
SRR0 0000000000000000 SRR1 0000000000000000 SDR1 0000000000000000
(qemu)
TB and DECR changed but NIP is still at 0xfff00100 and not at
0xfff02378 (0xfff00100: b 0xfff02378).
Same for powerpc64-linux-gnu-gdb 7.2, except that file .../obj-ppc/
openbios-qemu.elf.nostrip works there.
It seems it's the combination of ppc64-softmmu and 32-bit obj-ppc/
openbios-qemu.elf that doesn't work. For obj-ppc64/openbios-qemu.elf
stepi and cont work just fine!
=> We arrive in compute_ramsize; my hunch is that the bl setup_mmu
needs to be changed to dereference the function descriptor on ppc64.
Andreas
More information about the OpenBIOS
mailing list