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

[Jan Kiszka]

Jun Koi wrote:
> On Tue, Apr 27, 2010 at 6:30 PM, Jan Kiszka <address@hidden> wrote:
>> Jun Koi wrote:
>>> On Tue, Apr 27, 2010 at 5:10 PM, Jan Kiszka <address@hidden> 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.

It would report "hardware watchpoint" for a hard one. Just "watchpoint"
means it's emulated and will cause the stop-and-go you see.

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

E14 here means that the memory cannot be read. So it is in fact a
non-visible address at the time you try to set the watchpoint.

> Sending packet: $vCont;s:1;c#c1...Ack
> Packet received: T05thread:01;
> Sending packet: $g#67...Ack
> Packet received:
> 080000002400000015a6517702a6517774e1a902b0e1a902981e11006ba651774b63e877970200001b0000002300000023000000230000003b0000000000000000000000af4e0b0000001a040000405100005c936bca0800864d0000d1e95e8f000000000000ce4bf207000048f807000000000000000000000000000000000000c0e1c71040cd9c99999999c9cc19407f02000000010000000000000000000000000000000000000000000000000000db01917c000000000000000040607a60661b0000820d00000d010000000000001904000000000000000000000000000000000000000000000000000000000000f65c000000000000f7010000e50800000000000075000000000000000a000000380000002f060000050000001e00000000000000000000000000000000000000801f0000
> .....
> 
> 
> Thanks,
> J

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux