From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16521 invoked by alias); 14 Nov 2005 13:42: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 16507 invoked by uid 22791); 14 Nov 2005 13:42:47 -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 13:42:47 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1EbebX-0006LI-Rs for gdb@sources.redhat.com; Mon, 14 Nov 2005 16:42:45 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1EbebG-0006JZ-Fm; Mon, 14 Nov 2005 16:42:22 +0300 From: Vladimir Prus To: Johan Rydberg Subject: Re: read watchpoints ignored? Date: Mon, 14 Nov 2005 13:42:00 -0000 User-Agent: KMail/1.7.2 Cc: Daniel Jacobowitz , Eli Zaretskii , gdb@sources.redhat.com References: <200511111622.01337.ghost@cs.msu.su> <20051114024345.GB10567@nevyn.them.org> <43788E28.90108@virtutech.com> In-Reply-To: <43788E28.90108@virtutech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511141642.22179.ghost@cs.msu.su> X-SW-Source: 2005-11/txt/msg00264.txt.bz2 On Monday 14 November 2005 16:16, Johan Rydberg wrote: > Daniel Jacobowitz wrote: > > 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 happen to have access to a target that supports true read watchpoints, > and the following patch seems to do the trick, at least for the testcase > that Vladimir provided. This essentially disables read watchpoints. What's the point in first implementing read watchpoints in a target, and then disabling them completely in gdb? Should be then disallow "read watchpoint" packet in the remote protocol? I don't yet have specific *real-world* examples, but using "is the value different from the value last time we stopped" as a heuristic to decide if we hit write watchpoint or read watchpoint seems fragile. - Volodya