Re: [Qemu-devel] Using gdb to debug early kernel boot?

[Alexander Graf]

On Feb 11, 2008, at 9:29 AM, Rob Landley wrote:

> I'm trying to use gdb -s to debug the early boot of the sh4 kernel,  
> but it's
> not liking me.
>
> It does this:
>
> > qemu-system-sh4 -s -S -M r2d -kernel arch/sh/boot/zImage
> ... wait for gdb ...
> > qemu: fatal: Trying to execute code outside RAM or ROM at 0x88800058
> >
> > pc=0x88800058 sr=0x400000f0 pr=0x00000000 fpscr=0x00040001
> > r0=0x88800058 r1=0xabffffe0 r2=0xdc800000 r3=0x88800000
> > r4=0x410ed11e r5=0xd211c711 r6=0x89253020 r7=0xd0193208
> > r8=0x2019e1e0 r9=0x6103d30f r10=0x64123128 r11=0x56125511
> > r12=0x00000000 r13=0x00000000 r14=0x00000000 r15=0x00000000
> > r16=0x00000000 r17=0x400000f0 r18=0x00000000 r19=0x00000000
> > r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
> > Aborted (core dumped)
>
> (Which is the same behavior without -s -S).  Over in the gdb  
> session, I run
> gdb vmlinux and then:

This means that qemu is unable to handle something, whatever that  
something might be. As soon as this happens, qemu quits and doesn't  
tell gdb anything about it. So in gdb's side the gdbserver simply  
died, which results in a watchdog timeout.

> > (gdb) target remote localhost:1234
> > Remote debugging using localhost:1234
> > warning: shared library handler failed to enable breakpoint
> > 0x00000000 in ?? ()
> > (gdb) c
> > Continuing.
> > Watchdog has expired.  Target detached.
> > (gdb)
>
> At which point the qemu instance in the other window has crashed.
>
> Am I doing it wrong?

You might want to set a breakpoint at a pc where the virtual machine  
still lives. I guess that's 0x88800058 for you, so a "break  
*0x88800058" might help here. You could also enable in_asm debugging  
(if that's available on sh4) and take a look at the last translated  
chunk to find a reasonable address to break on.

Alex