From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2321 invoked by alias); 19 Feb 2006 18:31:46 -0000 Received: (qmail 2308 invoked by uid 22791); 19 Feb 2006 18:31:44 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 19 Feb 2006 18:31:40 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 0784348CDEF; Sun, 19 Feb 2006 13:31:38 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12030-01-10; Sun, 19 Feb 2006 13:31:37 -0500 (EST) Received: from [127.0.0.1] (dhcp02.adacore-vt.com [12.160.210.172]) by nile.gnat.com (Postfix) with ESMTP id B0E0448CDEE; Sun, 19 Feb 2006 13:31:37 -0500 (EST) Message-ID: <43F8B988.2030509@adacore.com> Date: Sun, 19 Feb 2006 18:44:00 -0000 From: Robert Dewar User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Koning , eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints References: <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> <17400.46393.531000.150247@gargle.gargle.HOWL> <20060219181912.GA19352@nevyn.them.org> In-Reply-To: <20060219181912.GA19352@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00252.txt.bz2 Daniel Jacobowitz wrote: > Because it's likely to mess up the rest of the user experience. > > If you have the option to stop before the store has executed, then > there's a choice: fast-forward to after the store, or show the user > that the store is about to occur. Right now, as Eli and I discussed > yesterday, we do the former. There's two advantages in this: we're > consistent between platforms with different capabilities, and it's > clear that the watchpoint won't be re-hit when we continue. Yes, obviously you want to point to the store that caused the change if you have this information. Yes, obviously when you continue, you want to continue from the point at which the watchpoint was signalled. > But you're talking about something different: retrieving or deducing > a different, related PC value and displaying source where the store > occured. Right, that's what is needed > > While this is useful, it needs to be done separately from the view we > present to the user of "where you are right now", which is what the > displayed source corresponds to. Otherwise, the user will be presented > a view of the world in which the store hasn't happened yet, but > discover that, in fact, it has! Absolutely, presenting the location of the store as where you are now would be plain wrong I think. > > Now, could we separately show "watchpoint occured at foo.c:15" if the > hardware permits? Yeah, sure. Yes, that seems the most desirable solution (and the only possible acceptable improvement to the current behavior). Changing things to fudge the location to the store would indeed be confusing. >