|
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'snot 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 rungdb 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
[Prev in Thread] | Current Thread | [Next in Thread] |