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