Re: [Qemu-devel] Qemu ARM9 weirdness

[Peter Maydell]

On 24 March 2014 19:49, Joel Fernandes <address@hidden> wrote:
> Now, I start gdb with -s -S options to halt on startup, and step
> through, each time I'm dumping the register set:
> ..
> Reading symbols from /home/joel/data/repo/linux-omap1/vmlinux...done.
> (gdb) info registers
> r0             0x0      0
> r1             0x0      0
> r2             0x0      0
> r3             0x0      0
> r4             0x0      0
> r5             0x0      0
> r6             0x0      0
> r7             0x0      0
> r8             0x0      0
> r9             0x0      0
> r10            0x0      0
> r11            0x0      0
> r12            0x0      0
> sp             0x0      0x0 <__vectors_start>
> lr             0x0      0
> pc             0x10000000       0x10000000 <stext>
> cpsr           0x400001d3       1073742291
>
> (gdb) si
> 93              mrc     p15, 0, r9, c0, c0              @ get processor id

Here gdb isn't printing the instruction it's actually about
to execute. It's looking at the PC and some debug information
and printing a line from the source code. Can you tell gdb
"disp /3i $pc" ? That will make it display the next 3
instructions every time it stops. Then we can see what
instructions we're really executing -- if the source info
and your binary are out of sync then gdb's display of
source file lines will be misleading you.

In particular I'm pretty sure the instructions you're actually
executing are the ones from QEMU's tiny kernel bootloader
stub in hw/arm/boot.c:

    { 0xe3a00000 }, /* mov     r0, #0 */
    { 0xe59f1004 }, /* ldr     r1, [pc, #4] */
    { 0xe59f2004 }, /* ldr     r2, [pc, #4] */
    { 0xe59ff004 }, /* ldr     pc, [pc, #4] */
    { 0, FIXUP_BOARDID },
    { 0, FIXUP_ARGPTR },
    { 0, FIXUP_ENTRYPOINT },
    { 0, FIXUP_TERMINATOR }

and either your debug information is for the wrong kernel
or you've accidentally told gdb the wrong start address for
the kernel and all its symbols are at wrong addresses.
You can see from the register info dumps that we're loading
r0, r1 and r2 and then jump to 0x10010000. Your gdb
thinks that's <omap_request_dma+284> and I'm pretty
sure it's wrong about that.

thanks
-- PMM