From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22646 invoked by alias); 17 Feb 2006 21:43:09 -0000 Received: (qmail 22638 invoked by uid 22791); 17 Feb 2006 21:43:09 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 17 Feb 2006 21:43:08 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FADNX-0000OA-BD; Fri, 17 Feb 2006 16:43:03 -0500 Date: Fri, 17 Feb 2006 22:12:00 -0000 From: Daniel Jacobowitz To: Paul Koning Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints Message-ID: <20060217214303.GA1375@nevyn.them.org> Mail-Followup-To: Paul Koning , eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com References: <20060217194426.GA28988@nevyn.them.org> <17398.11182.747232.774924@gargle.gargle.HOWL> <20060217200712.GB30145@nevyn.them.org> <17398.12047.624911.347942@gargle.gargle.HOWL> <20060217202047.GC30881@nevyn.them.org> <17398.15554.431196.208031@gargle.gargle.HOWL> <20060217211942.GA609@nevyn.them.org> <17398.16942.92466.13879@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17398.16942.92466.13879@gargle.gargle.HOWL> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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 X-SW-Source: 2006-02/txt/msg00228.txt.bz2 On Fri, Feb 17, 2006 at 04:37:50PM -0500, Paul Koning wrote: > Daniel> What I'm maintaining is that we shouldn't "sort this out". > Daniel> What we display should be, IMO, all the events which we > Daniel> consider to have logically occurred in the current > Daniel> conditions. The value of a watchpoint has changed since we > Daniel> last checked it? Report the watchpoint. We've reached the > Daniel> PC of a breakpoint? Report the breakpoint. > > Daniel> What you're suggesting would have two stops at identical PC > Daniel> values. You'd want to say continue and have GDB stop again, > Daniel> right away, without executing any instructions. I'd find > Daniel> that much more confusing! > > Maybe you find it confusing because you're trying to reason about this > at the machine code level. Look at the source line level instead. It's precisely because I am reasoning about this at the source code level that I find it confusing; we are stopped at the source location of the breakpoint. The fact that the breakpoint hasn't physically triggered is, as far as I'm concerned, just an implementation detail. Please take another look at my single-step example in the last message. > If you watch foo, you should be told about watchpoint stops at lines > that touch foo. You should not be told about breaks in other lines. > If you hit at watchpoint in line 421, and you continue, and you had > defined a breakpoint in line 422, you would expect that breakpoint to > fire because 422 != 421. But you don't "hit a watchpoint in line 421". When you hit the watchpoint, you are already at line 422. There's no way to "back up" the view we prevent to the user (excluding simulators); for instance the store may have been in the branch delay slot, so we could have come from absolutely anywhere. Other architectures may trigger the watchpoint multiple cycles later when the pipeline has cleared up a bit. Your later comment that "watch exceptions are caused by the instruction at PC-size" assumes far too much. If there were a way to back up the view, and we did it, then of course I'd agree we weren't stopped at the breakpoint. -- Daniel Jacobowitz CodeSourcery