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