[Qemu-devel] Re: Problem with watchpoint in gdbstub

[Jun Koi <junkoi2004@gmail.com>]

On Tue, Apr 27, 2010 at 6:30 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Jun Koi wrote:
>> On Tue, Apr 27, 2010 at 5:10 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> Jun Koi wrote:
>>>> Hi,
>>>>
>>>> I am trying to debug a VM using gdb. I connected gdb to Qemu (latest
>>>> code from git repo), and issued below command:
>>>>
>>>> ...
>>>> (gdb) watch *0x77f44cd8
>>>> (gdb) c
>>>>
>>>> The idea is to catch the write access to address 0x77f44cd8.
>>>>
>>>> But after the "c" command, I saw that the window title of my VM
>>>> continuously flip between "QEMU [Stopped]" and "QEMU", non-stop.
>>>> This makes the VM unusable.
>>>>
>>>> Is it a bug? Anybody sees the same problem?
>>> I would bet your watchpoint was established by gdb as a software
>>> watchpoint. In that case gdb will step through the target, checking
>>> after each instruction if the memory changed.
>>
>> But that is certainly not the reason of the symptom I saw.
>>
>
> So what does "i b" report about your watchpoint? Hard or soft?

It says nothing about hard or soft: it just reports I have one watchpoint.

>
>>
>>> Is that address valid at the time gdb wants to install it? I saw gdb
>>> choosing a software watchpoint before when it wasn't.
>>
>> Yes, that address is valid.
>
> You could also try "set debug remote 1" to see what gdb does when it
> stops and resumes the guest continuously.

Ah I dont know this, thanks!

And now I can see that gdb repeatedly sends a lot of commands to Qemu.
All the repeated messages look like a copy of the below text. Do you
have any idea?

.....
Sending packet: $m77f44cd2,4#02...Ack
Packet received: E14
Sending packet: $vCont;s:1;c#c1...Ack
Packet received: T05thread:01;
Sending packet: $g#67...Ack
Packet received:
080000002400000015a6517702a6517774e1a902b0e1a902981e11006ba651774b63e877970200001b0000002300000023000000230000003b0000000000000000000000af4e0b0000001a040000405100005c936bca0800864d0000d1e95e8f000000000000ce4bf207000048f807000000000000000000000000000000000000c0e1c71040cd9c99999999c9cc19407f02000000010000000000000000000000000000000000000000000000000000db01917c000000000000000040607a60661b0000820d00000d010000000000001904000000000000000000000000000000000000000000000000000000000000f65c000000000000f7010000e50800000000000075000000000000000a000000380000002f060000050000001e00000000000000000000000000000000000000801f0000
.....


Thanks,
J