[Qemu-devel] Problem with watchpoint in gdbstub

[Qemu-devel] Problem with watchpoint in gdbstub

[Jun Koi]

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?

Thanks,
Jun

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

[Jan Kiszka]

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.

Is that address valid at the time gdb wants to install it? I saw gdb
choosing a software watchpoint before when it wasn't.

Jan

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

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

[Jun Koi]

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.


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

thanks,
J

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

[Jan Kiszka]

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?

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

Jan

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

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

[Jun Koi]

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

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

[Jan Kiszka]

Jun Koi wrote:
> 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.

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