From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10451 invoked by alias); 17 Feb 2006 21:19:53 -0000 Received: (qmail 10442 invoked by uid 22791); 17 Feb 2006 21:19:52 -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; Fri, 17 Feb 2006 21:19:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FAD0x-0000EN-1t; Fri, 17 Feb 2006 16:19:43 -0500 Date: Fri, 17 Feb 2006 21:43:00 -0000 From: Daniel Jacobowitz To: Paul Koning Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: reporting of multiple breakpoints Message-ID: <20060217211942.GA609@nevyn.them.org> Mail-Followup-To: Paul Koning , eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17398.15554.431196.208031@gargle.gargle.HOWL> 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/msg00226.txt.bz2 On Fri, Feb 17, 2006 at 04:14:42PM -0500, Paul Koning wrote: > 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. 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. Try single-stepping up to a breakpoint if that clarifies things: 4 main (int argc, char **argv) 5 { 6 printf ("Hello world\n"); 7 return 0; 8 } (gdb) b 7 Breakpoint 2 at 0x80483a4: file debugging/printf.c, line 7. (gdb) s Hello world Breakpoint 2, main (argc=1, argv=0xbfe9b154) at debugging/printf.c:7 7 return 0; > 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. What I'm maintaining is that we shouldn't "sort this out". What we display should be, IMO, all the events which we consider to have logically occurred in the current conditions. The value of a watchpoint has changed since we last checked it? Report the watchpoint. We've reached the PC of a breakpoint? Report the breakpoint. What you're suggesting would have two stops at identical PC values. You'd want to say continue and have GDB stop again, right away, without executing any instructions. I'd find that much more confusing! -- Daniel Jacobowitz CodeSourcery