From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15848 invoked by alias); 19 Feb 2006 18:54:23 -0000 Received: (qmail 15835 invoked by uid 22791); 19 Feb 2006 18:54:22 -0000 X-Spam-Check-By: sourceware.org Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 19 Feb 2006 18:54:21 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k1JIsJTY013674 for ; Sun, 19 Feb 2006 13:54:19 -0500 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k1JIsJGF013669; Sun, 19 Feb 2006 13:54:19 -0500 Received: from PKONING.equallogic.com ([172.16.3.66]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 13:54:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17400.48853.906000.28206@gargle.gargle.HOWL> Date: Sun, 19 Feb 2006 19:30:00 -0000 From: Paul Koning To: dewar@adacore.com 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> <43F8BCA3.6060409@adacore.com> 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/msg00255.txt.bz2 >>>>> "Robert" == Robert Dewar writes: Robert> 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. Robert> You are NOT telling the user that, the current location is Robert> the point at which you stopped. I think it would be actively Robert> confusing to pretend you stopped at the store when you did Robert> not. Robert> Fudging the current location seems wrong to me. Robert> It *is* a good idea to tell the user where the store was if Robert> you know, but that's completely different from the Robert> information as to where you stopped. Robert> In some hardware debuggers, you can stop several instructions Robert> past the store, but you know where the store is. It would be Robert> really confusing to a user to list variables and see that Robert> assignments past the supposed current location have already Robert> occurred in unoptimized code. That's true. That isn't the case in the platform I know best -- there it wouldn't be misleading to report the store point only, because nothing else has happened yet. But if you have a deep pipe that does run to completion, then things would be different. So yes, reporting something like "stopped at foo.c:425 due to a store watchpoint at foo.c:421" would be ideal. paul