From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24036 invoked by alias); 17 Feb 2006 20:06:55 -0000 Received: (qmail 24022 invoked by uid 22791); 17 Feb 2006 20:06:54 -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:06:01 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FABra-0007vO-7l; Fri, 17 Feb 2006 15:05:58 -0500 Date: Fri, 17 Feb 2006 20:08:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints Message-ID: <20060217200558.GA30145@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> 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/msg00206.txt.bz2 On Fri, Feb 17, 2006 at 09:56:46PM +0200, Eli Zaretskii wrote: > > Date: Fri, 17 Feb 2006 14:44:26 -0500 > > From: Daniel Jacobowitz > > Cc: Vladimir Prus , gdb@sources.redhat.com > > > > There are two events in hardware, yes - but "GDB will always see these > > two as separate events" is not accurate. Suppose we've got an > > instruction at foo+0x10 that stores to a watched address and at > > foo+0x16 that has a breakpoint set on it. The watchpoint will trigger, > > stopping GDB at foo+0x16. At this point, we were stopped by the > > watchpoint, but we'll never hit the breakpoint - if the user "continue"s, > > GDB will politely step around the breakpoint. In effect, we've > > hit the watchpoint and breakpoint simultaneously, and IMO it would > > be appropriate to let the user know about both of them. > > Why do we step around the breakpoint? As long as we do that, the > breakpoint never happened, and we don't need to announce it. If we > _want_ to announce it, we should stop stepping around it, IMHO. All this long predates me, you understand. I can only give you my interpretation, not a real reason. But the status quo seems reasonable enough to me. 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. 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. -- Daniel Jacobowitz CodeSourcery