From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8416 invoked by alias); 19 Feb 2006 18:44:58 -0000 Received: (qmail 8404 invoked by uid 22791); 19 Feb 2006 18:44:57 -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:44:55 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 7B70348CDA6; Sun, 19 Feb 2006 13:44:53 -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 13708-01-3; Sun, 19 Feb 2006 13:44:53 -0500 (EST) Received: from [127.0.0.1] (dhcp02.adacore-vt.com [12.160.210.172]) by nile.gnat.com (Postfix) with ESMTP id 9E99048CBDF; Sun, 19 Feb 2006 13:44:52 -0500 (EST) Message-ID: <43F8BCA3.6060409@adacore.com> Date: Sun, 19 Feb 2006 19:05:00 -0000 From: Robert Dewar User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Koning CC: drow@false.org, gdb@sourceware.org Subject: Re: MI: reporting of multiple breakpoints 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> <17400.46121.875000.537237@gargle.gargle.HOWL> <20060219182038.GB19352@nevyn.them.org> <17400.47897.765000.695598@gargle.gargle.HOWL> In-Reply-To: <17400.47897.765000.695598@gargle.gargle.HOWL> 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/msg00254.txt.bz2 Paul Koning wrote: > Ok, my point is that we can do better. Your point (previous message) > is that you don't think what I'm suggesting is better. I guess we'll > just disagree on that. I prefer to tell users a store happened in a > source line that contains an assignment, rather than a source line > that doesn't. The fact that some hardware can't do that doesn't alter > that -- we don't and shouldn't just offer lowest common denominator. You are NOT telling the user that, the current location is the point at which you stopped. I think it would be actively confusing to pretend you stopped at the store when you did not. Fudging the current location seems wrong to me. It *is* a good idea to tell the user where the store was if you know, but that's completely different from the information as to where you stopped. In some hardware debuggers, you can stop several instructions past the store, but you know where the store is. It would be really confusing to a user to list variables and see that assignments past the supposed current location have already occurred in unoptimized code.