From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21024 invoked by alias); 18 Feb 2006 11:10:20 -0000 Received: (qmail 21015 invoked by uid 22791); 18 Feb 2006 11:10:19 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 18 Feb 2006 11:10:19 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-139-42.inter.net.il [84.228.139.42]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DOY27774 (AUTH halo1); Sat, 18 Feb 2006 13:10:14 +0200 (IST) Date: Sat, 18 Feb 2006 11:39:00 -0000 Message-Id: From: Eli Zaretskii To: Paul Koning , ghost@cs.msu.su CC: gdb@sources.redhat.com In-reply-to: <20060217211942.GA609@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 17 Feb 2006 16:19:43 -0500) Subject: Re: MI: reporting of multiple breakpoints Reply-to: Eli Zaretskii References: <20060217153211.GA21402@nevyn.them.org> <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> 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/msg00233.txt.bz2 > Date: Fri, 17 Feb 2006 16:19:43 -0500 > From: Daniel Jacobowitz > Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com > > > Exactly my point. The case you're talking about is the opposite of > > the one I was talking about. > > > > The program runs, executes the store into foo. GDB should report > > hitting the watchpoint on foo, and should NOT report hitting the > > breakpoint at 422. > > > > User says "step". We execute one instruction, which is the breakpoint > > trap, and report that as the breakpoint at line 422. User is happy. > > No, this is not the opposite of what I described; could you explain why > you think it is? It's indistinguishable from what I described. If we > set the PC to the PC of the breakpoint, we assume we are past (have > already hit) the breakpoint. Therefore when we're stopped by a > watchpoint at the PC of a breakpoint, it's sensible to treat this > situation to the user as if we have already hit the breakpoint. I think at the core of this argument is this problem: there's no PC value that is _between_ two adjacent instructions. Thus, being _after_ an instruction at a certain value of PC means that we at the same time are _at_ or _on_ the next instruction at PC+1. And being _at_ an instruction where we put a breakpoint means that the breakpoint have already triggered, since breakpoints are expected to break _before_ the instruction executes. Do you both agree with this interpretation? If so, you should also both agree that being _after_ an instruction that wrote into a watched data location also means we are at the same precise location where a breakpoint was already supposed to break. There's nothing in between these two locations, no place where we could stop _before_ getting to a place where a breakpoint should break. > What I'm maintaining is that we shouldn't "sort this out". What we > display should be, IMO, all the events which we consider to have > logically occurred in the current conditions. The value of a > watchpoint has changed since we last checked it? Report the > watchpoint. We've reached the PC of a breakpoint? Report the > breakpoint. I agree. > What you're suggesting would have two stops at identical PC values. Right. > You'd want to say continue and have GDB stop again, right away, without > executing any instructions. I'd find that much more confusing! Agreed.