Re: [Qemu-devel] Qemu ARM9 weirdness

[Joel Fernandes]

On Mon, Mar 24, 2014 at 7:25 PM, Peter Maydell <address@hidden> wrote:
> 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:
>

Thanks, that was indeed the case. :) Turns out also that I was
circling within the kernel decompressor as well which is not a part of
the ELF start.

>     { 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.

Yes, messed up the symbol addresses. Thinks look good now.

Thanks,

-Joel