From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6018 invoked by alias); 17 Feb 2006 20:19:10 -0000 Received: (qmail 6010 invoked by uid 22791); 17 Feb 2006 20:19:09 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 20:19:09 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-152-98.inter.net.il [80.230.152.98]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DOW64401 (AUTH halo1); Fri, 17 Feb 2006 22:19:03 +0200 (IST) Date: Fri, 17 Feb 2006 20:22:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus , gdb@sources.redhat.com In-reply-to: <20060217200558.GA30145@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 17 Feb 2006 15:05:58 -0500) Subject: Re: MI: reporting of multiple breakpoints Reply-to: Eli Zaretskii References: <20060217153211.GA21402@nevyn.them.org> <20060217194426.GA28988@nevyn.them.org> <20060217200558.GA30145@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/msg00215.txt.bz2 > 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. And indeed we do announce both watchpoints today, right? > 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?