From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20496 invoked by alias); 17 Feb 2006 21:37:56 -0000 Received: (qmail 20486 invoked by uid 22791); 17 Feb 2006 21:37:55 -0000 X-Spam-Check-By: sourceware.org Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 21:37:54 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k1HLbqTa009079 for ; Fri, 17 Feb 2006 16:37:52 -0500 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k1HLbpGF009074; Fri, 17 Feb 2006 16:37:51 -0500 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 16:37:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17398.16942.92466.13879@gargle.gargle.HOWL> Date: Fri, 17 Feb 2006 21:56:00 -0000 From: Paul Koning To: drow@false.org Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints 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/msg00227.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> No, this is not the opposite of what I described; could you Daniel> explain why you think it is? It's indistinguishable from Daniel> what I described. If we set the PC to the PC of the Daniel> breakpoint, we assume we are past (have already hit) the Daniel> breakpoint. Therefore when we're stopped by a watchpoint at Daniel> the PC of a breakpoint, it's sensible to treat this situation Daniel> to the user as if we have already hit the breakpoint. You talked about a case where a user sets $pc. That doesn't show up in my discussion at all. The program is just running, and hits a watchpoint triggered by an action in source line 421. It is really a bad idea to pretend that we've stopped at a breakpoint on line 422. The fact that some hardware may take the exception with PC pointing at 422 is not a valid reason to do otherwise. It's conceivable that it's unavoidable, if the hardware doesn't distinguish watchpoint from breakpoint exceptions. But, for example, on MIPS the two are distinct. So if I get a watch exception at PC 0x12340, I know that the instruction that caused the watch is 0x1233c, which is line 421, so that's what should be reported. The instruction that caused the exception is NOT the break, first of all because it's at 0x12340 which is not the instruction address that caused the exception, and second because the exception type (watch exception) cannot be produced by a break instruction. 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. 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. For that matter, if you do this, then in fact you DID execute one instruction, namely the break instruction. Also, if you recognize that watch exceptions are caused by the instruction at PC-size, and break instructions are caused by the instruction at PC, it all makes even more sense -- the triggering instruction is NOT the same, and if you take BOTH the exception type AND the exception PC into account in the analysis, you will get the correct answer. As far as I remember from the break/watch analysis code, this is all perfectly doable, even if it isn't the way it's currently coded. paul