[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Graf
Subject: Re: [Qemu-devel] Using gdb to debug early kernel boot?
Date: Mon, 11 Feb 2008 10:31:07 +0100

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
Watchdog has expired.  Target detached.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]