From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30984 invoked by alias); 14 Nov 2005 04:38:31 -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 30947 invoked by uid 22791); 14 Nov 2005 04:38:29 -0000 Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 14 Nov 2005 04:38:29 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-15-81.inter.net.il [80.230.15.81]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BYF14149 (AUTH halo1); Mon, 14 Nov 2005 06:38:12 +0200 (IST) Date: Mon, 14 Nov 2005 04:38:00 -0000 Message-Id: From: Eli Zaretskii To: gdb@sources.redhat.com, Vladimir Prus In-reply-to: <20051114024345.GB10567@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 13 Nov 2005 21:43:45 -0500) Subject: Re: read watchpoints ignored? Reply-to: Eli Zaretskii References: <200511111622.01337.ghost@cs.msu.su> <20051113164546.GA465@nevyn.them.org> <20051114024345.GB10567@nevyn.them.org> X-SW-Source: 2005-11/txt/msg00258.txt.bz2 > Date: Sun, 13 Nov 2005 21:43:45 -0500 > From: Daniel Jacobowitz > Cc: gdb@sources.redhat.com, Vladimir Prus > > > > 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. We need to find a way to get GDB to check whether the watchpoint fired during such stepping. > I'm talking about watchpoint_check. If that had been called, we would > have updated the value stored in the watchpoint for "a", and at the > next read watchpoint, it would not appear to have changed. I think we need call watchpoint_check only if target_stopped_data_address says the watchpoint fired. > Fortunately any platform with read watchpoints probably also has access > watchpoints, so we can get by with using those instead. Exactly. > But the first read after the value changes has a high chance of > being the important one while debugging. I think the current code should handle this well. But perhaps you are thinking about some particular situation where it won't, so please show the code you had in mind. > 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". That's fine with me.