From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12011 invoked by alias); 14 Nov 2005 10:10:49 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11980 invoked by uid 22791); 14 Nov 2005 10:10:46 -0000 Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 14 Nov 2005 10:10:46 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1EbbIR-0003su-Ep for gdb@sources.redhat.com; Mon, 14 Nov 2005 13:10:44 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1EbbIM-0003sR-Je; Mon, 14 Nov 2005 13:10:38 +0300 From: Vladimir Prus To: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: read watchpoints ignored? Date: Mon, 14 Nov 2005 10:10:00 -0000 User-Agent: KMail/1.7.2 References: <200511111622.01337.ghost@cs.msu.su> <20051114024345.GB10567@nevyn.them.org> In-Reply-To: <20051114024345.GB10567@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511141310.38302.ghost@cs.msu.su> X-SW-Source: 2005-11/txt/msg00261.txt.bz2 > > > it is not updating the values > > > of watchpoints before resuming the instruction. That instruction > > > happened to modify the value behind a read watchpoint. > > > > Then that's the bug, I'd say. Do you agree that this is what we > > should fix to solve this bug? Because the following discussion of > > problems with read watchpoints is only remotely related to the bug > > reported by Vladimir. > > Yes, certainly this is the bug, I just don't know which way to fix it. Well, there are two distinct bugs there. First is that "breakpoint on store instruction", where watched value should be re-read by gdb, but is not. Second is that for targets with real read watchpoints, the problem is present anyway. When I do "target remote :1234" the current PC is before assignment, since watchpoint is read-only, gdb does not stop on write, and ignores first read of variable. I can't fix the first problem yet, because I'm not familiar with the code. About the second... > > > This should be controlled by an architecture method indicating that > > > there are only access watchpoints. > > > > And then what? disable `rwatch'? I object to such ``solution'', since > > the emulated read watchpoints proved to be most useful to me since the > > code we discuss was introduced. > > I thought this was fairly straightforward, so I didn't go into detail. > Certainly there's no reason to disable rwatch. Conditionalize "skip > this watchpoint if the value has changed" on "this is really an access > watchpoint because the target does not support read watchpoints". > > It should be trivial to fix if you had a platform with read watchpoints > handy. Which I don't easily. .. I can try adding extra method to target ops, and for remote target, implement it by returning the value of remote_protocol_Z[Z_PACKET_READ_WP].support Should I do this? - Volodya