From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6hvv-00089v-0j for qemu-devel@nongnu.org; Tue, 27 Apr 2010 06:22:27 -0400 Received: from [140.186.70.92] (port=57418 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6hvm-00089L-KF for qemu-devel@nongnu.org; Tue, 27 Apr 2010 06:22:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6hvj-0004ZC-Ho for qemu-devel@nongnu.org; Tue, 27 Apr 2010 06:22:18 -0400 Received: from goliath.siemens.de ([192.35.17.28]:18133) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6hvj-0004Yj-7r for qemu-devel@nongnu.org; Tue, 27 Apr 2010 06:22:15 -0400 Message-ID: <4BD6BAD0.2050903@siemens.com> Date: Tue, 27 Apr 2010 12:22:08 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4BD69C10.50606@siemens.com> <4BD6AE9C.2060704@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Problem with watchpoint in gdbstub List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jun Koi Cc: "qemu-devel@nongnu.org" Jun Koi wrote: > On Tue, Apr 27, 2010 at 6:30 PM, Jan Kiszka wrote: >> Jun Koi wrote: >>> On Tue, Apr 27, 2010 at 5:10 PM, Jan Kiszka 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