From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6961 invoked by alias); 17 Feb 2006 21:14:54 -0000 Received: (qmail 6952 invoked by uid 22791); 17 Feb 2006 21:14:52 -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; Fri, 17 Feb 2006 21:14:50 +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 k1HLElTa006066 for ; Fri, 17 Feb 2006 16:14:48 -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 k1HLEiGF006061; Fri, 17 Feb 2006 16:14:47 -0500 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 16:14:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17398.15554.431196.208031@gargle.gargle.HOWL> Date: Fri, 17 Feb 2006 21:37:00 -0000 From: Paul Koning To: drow@false.org Cc: eliz@gnu.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> 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/msg00225.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> On Fri, Feb 17, 2006 at 03:16:15PM -0500, Paul Koning wrote: >> That's not the same case. I was going to say that both stops >> should be reported even if they are at the SAME address, then >> decided against that, as you did. >> >> But in the case we're talking about, you could have this source >> code: >> >> 421 foo=1; >> 422 bar=2; >> >> I set a breakpoint on line 422, and a watchpoint on "foo". >> Clearly those are very different -- line 422 doesn't touch foo, >> and the line that touches foo isn't line 422. GDB should not >> confuse those two things. If the hardware or GDB advances the PC >> across the watched instruction, that's very well but that doesn't >> mean GDB should believe the stop point is the instruction after. >> The stop point is the store into foo, which isn't line 422. Daniel> So? Daniel> The user does "set $var = $pc" after hitting the breakpoint Daniel> at bar. Then later they do jump *$var. They have every Daniel> right (IMO) to expect that they are, once again, after the Daniel> breakpoint at line 422, and that it won't be hit again - and Daniel> even though you could make a good argument for the opposite Daniel> case, this is how GDB has behaved for a long while. I think Daniel> you'll encounter just as manage strange cases if you reverse Daniel> it. Daniel> Another way to think about it, if this helps. Right now you Daniel> will not hit a GDB-requested event after "step" or "continue" Daniel> without executing at least one instruction. You might be Daniel> interrupted (by a trap instruction, an async signal, et Daniel> cetera). But GDB will do its level best to step when you ask Daniel> for a step, not hit a breakpoint that you've already noticed. 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. Maybe I'm messing up the discussion by being confused about what the problem is that started the thread. I thought what I heard is: the watchpoint traps with the PC pointing *after* the store, i.e., it points at the trap instruction, so it looks like two simultaneous stops. My point is that this is not correct reasoning: the watchpoint stop is at PC-instruction_size, which is in line 421 (last instruction of 421) and clearly different from line 422. Yes, the hardware reports PC, not PC-instruction_size, but that's GDB's job to sort out, not the user's. paul