From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26605 invoked by alias); 19 Feb 2006 18:13:27 -0000 Received: (qmail 26587 invoked by uid 22791); 19 Feb 2006 18:13:26 -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:13:25 +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 k1JIDNTa011530 for ; Sun, 19 Feb 2006 13:13:23 -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 k1JIDMGF011525; Sun, 19 Feb 2006 13:13:22 -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:13:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17400.46393.531000.150247@gargle.gargle.HOWL> Date: Sun, 19 Feb 2006 18:20:00 -0000 From: Paul Koning To: eliz@gnu.org Cc: drow@false.org, ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints References: <20060217153211.GA21402@nevyn.them.org> <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> <17398.16942.92466.13879@gargle.gargle.HOWL> 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/msg00249.txt.bz2 It's really frustrating that this is so hard to explain. Yes, it is likely that the exception PC for a watchpoint exception points after the store, not at it. And it certainly is always true that you want to resume after the store, not on it. However, the issue isn't the value of PC at the exception. The issue is: what user watch/break is reported, and what line is reported? My argument is: if the hardware permits you to know the PC of the store, then you can do a BETTER job helping the user, by translating the address of the store, NOT the exception PC, back into a line number. That way, you will tell the user that execution stopped at a source line that does a store, rather than a source line that does something entirely different. If the hardware allows this, why do anything less? paul