From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9128 invoked by alias); 17 Feb 2006 20:24:26 -0000 Received: (qmail 9120 invoked by uid 22791); 17 Feb 2006 20:24:25 -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 20:24:22 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FAC9L-0008GU-RR; Fri, 17 Feb 2006 15:24:19 -0500 Date: Fri, 17 Feb 2006 20:31:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints Message-ID: <20060217202419.GD30881@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: <20060217153211.GA21402@nevyn.them.org> <20060217194426.GA28988@nevyn.them.org> <20060217200558.GA30145@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/msg00218.txt.bz2 On Fri, Feb 17, 2006 at 10:19:12PM +0200, Eli Zaretskii wrote: > > Date: Fri, 17 Feb 2006 15:05:58 -0500 > > From: Daniel Jacobowitz > > Cc: Vladimir Prus , gdb@sources.redhat.com > > > > Consider a store which causes two user-placed watchpoints to trigger - > > this is pretty easy since there is a non-trivial mapping between user > > watchpoints and watched values. We want to report both watchpoints. > > But we were, physically, only stopped for one of them. > > No, I think we were stopped by both of them. They both watch the same > address, so they both fired when the location gets written. If they were set using the same watchpoint register, they "both" triggered trivially. If they were set using different hardware watchpoint resources, then the target almost certainly reported only one of them. > And indeed we do announce both watchpoints today, right? Yes, that's why I was drawing the parallel. > > It's the same thing with breakpoints. A breakpoint is "stop the > > program when you reach address FOO". We've reached address FOO; the > > fact that something _else_ caused us to stop at the same time seems > > only marginally relevant. > > > > We step around it because we want to announce the breakpoint when > > we first reach the relevant PC; if we're at FOO and say continue > > then normally we won't hit the breakpoint at FOO, because after > > hitting that breakpoint we present $pc == FOO to the user. > > But what about the commands associated with that breakpoint? We've > reached the address and stopped, allright, but we didn't run the > commands the user wanted us to, did we? We should run them when we stop. That's what I'm trying to say :-) -- Daniel Jacobowitz CodeSourcery