On 24 March 2014 19:49, Joel Fernandes <agnel.j...@gmail.com> 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