From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25340 invoked by alias); 19 Feb 2006 18:08:57 -0000 Received: (qmail 25332 invoked by uid 22791); 19 Feb 2006 18:08:57 -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:08:54 +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 k1JI8pTY011320 for ; Sun, 19 Feb 2006 13:08:52 -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 k1JI8pGF011308; Sun, 19 Feb 2006 13:08:51 -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:08:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17400.46121.875000.537237@gargle.gargle.HOWL> Date: Sun, 19 Feb 2006 18:19:00 -0000 From: Paul Koning To: eliz@gnu.org Cc: 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> 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/msg00248.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: >> Date: Fri, 17 Feb 2006 16:19:43 -0500 From: Daniel Jacobowitz >> Cc: eliz@gnu.org, ghost@cs.msu.su, >> gdb@sources.redhat.com >> >> > Exactly my point. The case you're talking about is the opposite >> of > the one I was talking about. >> > >> > The program runs, executes the store into foo. GDB should >> report > hitting the watchpoint on foo, and should NOT report >> hitting the > breakpoint at 422. >> > >> > User says "step". We execute one instruction, which is the >> breakpoint > trap, and report that as the breakpoint at line 422. >> User is happy. >> >> No, this is not the opposite of what I described; could you >> explain why you think it is? It's indistinguishable from what I >> described. If we set the PC to the PC of the breakpoint, we >> assume we are past (have already hit) the breakpoint. Therefore >> when we're stopped by a watchpoint at the PC of a breakpoint, it's >> sensible to treat this situation to the user as if we have already >> hit the breakpoint. Eli> I think at the core of this argument is this problem: there's no Eli> PC value that is _between_ two adjacent instructions. No, that isn't my point. My point is that, at least on some of the platforms, a watchpoint exception will deliver the PC of the instruction doing the store, or that PC can be deduced. Therefore, on such platforms, that is the PC that should be reported, which will make the report point to the right source line. Of course, the resume will not resume there, but GDB already has machinery for that. Daniel's comments are entirely valid for the case where you cannot know the PC of the store -- certainly in that case you may end up with a PC that happens to match that of a breakpoint, and in that case you may end up reporting the watchpoint stop at the break line, and end up not doing the break when you resume. Fine, if that's the best your hardware permits, but that isn't universally true. paul