On Sun, Jan 22, 2012 at 8:28 PM, Jan Kiszka <jan.kis...@web.de> wrote: > On 2012-01-22 20:25, Francis Moreau wrote: >> Hello, >> >> Thanks for you hints ! >> >> On Sun, Jan 22, 2012 at 7:49 PM, Jan Kiszka <jan.kis...@web.de> wrote: >>> On 2012-01-22 15:20, Francis Moreau wrote: >>>> Hello, >>>> >>>> I'm trying to debug a 64 bits kernel (3.2) using qemu (with and >>>> without KVM support). The host is also 64 bits. Version of gdb I'm >>>> using is 7.1. >>>> >>>> To do that I simply start qemu like the following: >>>> >>>> $ qemu-system-x86_64 -kernel bzImage -append "root=/dev/sda1 >>>> console=ttyS0 3" -serial stdio -S -s >>>> >>>> and in another term, I start gdb like this: >>>> >>>> $ gdb vmlinux >>>> $ target remote locahost:1234 >>>> $ b prepare_namespace >>>> $ continue >>>> Continuing. >>>> Remote 'g' packet reply is too long: af75919effffffff0............. >>>> >>>> So it fails when gdb stops on the breakpoint with the above message. >>>> >>>> If I try to dump the backtrace I got: >>>> >>>> $ bt >>>> Target is executing. >>>> $ info thread >>>> * 1 Thread 1 (CPU#0 [running]) (running) >>>> >>>> But the VM seems to be stopped because if I'm asking the status to qemu: >>>> >>>> $ info status >>>> VM status: paused >>>> >>>> I also tried qemu with KVM support but I get one more problem: gdb is >>>> ignoring my breakpoint. >>>> >>>> Could anybody help me to make gdb work ? >>> >>> When stopping the guest with -S before it booted, gdb will interrupt it >>> while it is still in 16-bit real mode. Later on, when Linux runs, the >>> guest is in 64-bit protected mode. gdb is not prepared for such a >>> switch. All you can do: >>> >>> - let the guest run until it surely reached 64-bit mode >>> - interrupt it and set a breakpoint at the desired early-boot location, >> >> So I let the kernel boot, and then I'm trying to start and connect gdb >> to qemu but unfortunately gdb is segfaulting when trying to connect :( > > Try gdb 7.3 or even latest development version (the latter is required > for module debugging - just in case).
OMG it's working ! One weird thing though: if I put "target remote localhost:1234" in .gdbinit then I'm getting this in gdb: /home/fmoreau/.gdbinit:1: Error in sourced command file: Remote 'g' packet reply is too long: c0f6ba3d0088fff.... I've no problem if I don't use .gdbinit. That's sad that setting arch doesn't work. > >> >>> important: if using KVM, set a hardware breakpoint! >> >> ah ok good to know, I'll try to use hw breakpoints. > > The reason is that software breakpoints are implemented under kvm by > patching breakpoint instructions into the guest - and those get > overwritten when reloading the kernel after reboot. Thanks for the information, using hw breakpoint with kvm works ! Thanks a lot ! -- Francis