Re: [Qemu-devel] Failed to use gdb with qemu 15.1 (with and without kvm support)

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

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.kiszka@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).

> 
>>  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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]