From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25635 invoked by alias); 20 Feb 2006 13:47:34 -0000 Received: (qmail 25625 invoked by uid 22791); 20 Feb 2006 13:47:34 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 20 Feb 2006 13:47:31 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBBNj-00036I-FY; Mon, 20 Feb 2006 08:47:15 -0500 Date: Mon, 20 Feb 2006 18:20:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Paul Koning , ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints Message-ID: <20060220134714.GA11865@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Paul Koning , ghost@cs.msu.su, gdb@sources.redhat.com References: <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> <20060219215433.GA25853@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i 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/msg00269.txt.bz2 On Mon, Feb 20, 2006 at 07:06:58AM +0200, Eli Zaretskii wrote: > The exception happens right when the store is written, and we find the > PC to be after the faulting instruction, when the inferior stops. The > faulting instruction is the one that corresponds to the previous PC > value. Yes. On x86 it's possible to deduce the "previous PC value" but that's not always the case. > > > Again, the place that caused the store is known (and shown to the > > > user), but the place where the inferior is stopped is a different > > > place on many architectures, including x86. Wed are arguing about the > > > latter, not the former. > > > > Could you give me an example? > > What should the example show? Us showing "the place that caused the store" to the user. I don't think we do this or have ever done this. > > I think that is desirable, but not at all what we do today - I have > > no idea how to retrieve the address of the store when I stop at a > > watchpoint. We show the old and new value, but that's it. > > We also show the current source line, don't we? Are you saying that > we show the wrong line? We show the old value, the new value, and the source line containing $pc, but not the location of the store. -- Daniel Jacobowitz CodeSourcery