From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28683 invoked by alias); 17 Feb 2006 21:56:54 -0000 Received: (qmail 28672 invoked by uid 22791); 17 Feb 2006 21:56:53 -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:56:52 +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 k1HLumTa011058 for ; Fri, 17 Feb 2006 16:56:48 -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 k1HLulGF011052; Fri, 17 Feb 2006 16:56:48 -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:56:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17398.18077.716159.385642@gargle.gargle.HOWL> Date: Sat, 18 Feb 2006 09:54: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: <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> <20060217214303.GA1375@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/msg00229.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: >> 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. Daniel> It's precisely because I am reasoning about this at the Daniel> source code level that I find it confusing; we are stopped at Daniel> the source location of the breakpoint. The fact that the Daniel> breakpoint hasn't physically triggered is, as far as I'm Daniel> concerned, just an implementation detail. Please take Daniel> 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. Daniel> But you don't "hit a watchpoint in line 421". When you hit Daniel> the watchpoint, you are already at line 422. There's no way Daniel> to "back up" the view we prevent to the user (excluding Daniel> simulators); for instance the store may have been in the Daniel> branch delay slot, so we could have come from absolutely Daniel> anywhere. Other architectures may trigger the watchpoint Daniel> multiple cycles later when the pipeline has cleared up a bit. Daniel> Your later comment that "watch exceptions are caused by the Daniel> instruction at PC-size" assumes far too much. Daniel> If there were a way to back up the view, and we did it, then Daniel> of course I'd agree we weren't stopped at the breakpoint. I see the point. If you have hardware that has imprecise watchpoint exceptions, then indeed you're hosed. You might be anywhere, and in that case the watchpoint feature is going to be quite unuseable because the user will be pointed at a source line that is potentially not even in the same source file as the triggering instruction. However, the fact that some architectures have imprecise watchpoints is no reason to force imprecision on those that can do better. In other words, this should be an example of target-dependent machinery: if the target has the ability to determine the "PC of the watchpoint trigger instruction" then it should do so, and the break/watch display reporting machinery should use that information to report the watchpoint at the "correct" source line. I thought such machinery already existed, but I may be mixed up with other target hooks or target macros that deal with advancing or backing up the PC at breakpoints and watchpoints. paul