On Mon, Mar 24, 2014 at 7:25 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> 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:
>
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
