From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29992 invoked by alias); 18 Feb 2006 15:47:03 -0000 Received: (qmail 29974 invoked by uid 22791); 18 Feb 2006 15:47:00 -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; Sat, 18 Feb 2006 15:46:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FAUIP-0005aw-7X; Sat, 18 Feb 2006 10:46:53 -0500 Date: Sat, 18 Feb 2006 17:28:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Paul Koning , ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints Message-ID: <20060218154653.GB21241@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Paul Koning , 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00237.txt.bz2 On Sat, Feb 18, 2006 at 01:10:13PM +0200, Eli Zaretskii wrote: > 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? This I agree with completely. > 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. And this. On Sat, Feb 18, 2006 at 01:33:37PM +0200, Eli Zaretskii wrote: > No, it's not a hardware limitation, it's a ``limitation'' (I think > it's rather a feature) of _any_ reasonable implementation of > watchpoints, even software watchpoints: a watchpoint _always_ breaks > _after_ the instruction that writes to the watched location. It > cannot be any other way, because no debugger and no hardware can > possibly know whether an instruction will write to an arbitrary > location before running that instruction. While I agree with your conclusions above, this bit's not right. (A) Hardware can pretty straightforwardly trigger the exception while executing the instruction, between address calculation and store completion, and back up the PC. I have been poring over the MIPS documentation, but I haven't worked out yet whether this happens or not. However, I think some platforms do - I think this is what HAVE_NONSTEPPABLE_WATCHPOINT is all about. HAVE_CONTINUABLE_WATCHPOINT, on the other hand, is going to usually imply that we stop after the event. (B) Most targets have few store instructions. Not x86, true. But for others, disassembling the instruction at $pc to see where it will read or write is pretty trivial. ARM has maybe a dozen relevant instructions at most. (C) Page protection write watchpoints will always fault before the store, and the OS will often provide the faulting address for you in the signal information. Do we want to uniformly present watchpoints as after-the-store, as a least common denominator and for consistency? If so, a reasonable sort of thing to do, then all of the first part of this message applies. If not, it applies to targets on which watchpoints stop after execution... > You seem to suggest that we back up one instruction after a watchpoint > triggers. Is that true? If so, I think it's not a good idea, since > (1) we'd have the watchpoint trigger again when we continue after > that, and (2) the user who knows (as they all should, IMHO) that a > watchpoint always triggers _after_ the code that wrote to the data > will be utterly confused by that. ... except for this, which is the same problem I described for breakpoints; that's a compelling reason to behave as we do now. -- Daniel Jacobowitz CodeSourcery