From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29392 invoked by alias); 18 Feb 2006 11:34:33 -0000 Received: (qmail 29382 invoked by uid 22791); 18 Feb 2006 11:34:33 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 18 Feb 2006 11:34:32 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HXK04604; Sat, 18 Feb 2006 13:33:43 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-84-228-139-42.inter.net.il [84.228.139.42]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CSP67967 (AUTH halo1); Sat, 18 Feb 2006 13:33:38 +0200 (IST) Date: Sat, 18 Feb 2006 15:28:00 -0000 Message-Id: From: Eli Zaretskii To: Paul Koning CC: drow@false.org, ghost@cs.msu.su, gdb@sources.redhat.com In-reply-to: <17398.16942.92466.13879@gargle.gargle.HOWL> (message from Paul Koning on Fri, 17 Feb 2006 16:37:50 -0500) Subject: Re: MI: reporting of multiple breakpoints Reply-to: Eli Zaretskii 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/msg00234.txt.bz2 > Date: Fri, 17 Feb 2006 16:37:50 -0500 > From: Paul Koning > Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com > > The fact that some hardware may take the exception with PC pointing at > 422 is not a valid reason to do otherwise. It's conceivable that it's > unavoidable, if the hardware doesn't distinguish watchpoint from > breakpoint exceptions. No, it's not a hardware limitation, it's a ``limitation'' (I think it's rather a feature) of _any_ reasonable implementation of watchpoints, even software watchpoints: a watchpoint _always_ breaks _after_ the instruction that writes to the watched location. It cannot be any other way, because no debugger and no hardware can possibly know whether an instruction will write to an arbitrary location before running that instruction. Therefore, when a watchpoint triggers, we will _always_ be after the instruction already executed. The only hardware-specific aspect here is whether the value of PC as reported by the target reflects that fact, but that's a quirk of the hardware, not of the reality (I think GDB fixes $pc to always behave as if the PC were after the instruction, to reflect the reality). In reality, the faulting instruction is always behind us, and we already are at the next instruction. In your example, the next instruction is the one where the user put the breakpoint, so we are _exactly_ at the place where it should break. In other words, if line 421 writes to a watched location, then when the watchpoint triggers, we are already after line 421, i.e. at line 422 (since, as I wrote earlier, there's no location between those two lines where we could be). > But, for example, on MIPS the two are > distinct. So if I get a watch exception at PC 0x12340, I know that > the instruction that caused the watch is 0x1233c, which is line 421, > so that's what should be reported. We know this on x86 as well, but this is a different issue. Knowing that the instruction at 0x1233c wrote to a watched address says nothing about _where_ is the PC of the program at the time we are told that. > The instruction that caused the exception is NOT the break, first of > all because it's at 0x12340 which is not the instruction address that > caused the exception, and second because the exception type (watch > exception) cannot be produced by a break instruction. You seem to suggest that we back up one instruction after a watchpoint triggers. Is that true? If so, I think it's not a good idea, since (1) we'd have the watchpoint trigger again when we continue after that, and (2) the user who knows (as they all should, IMHO) that a watchpoint always triggers _after_ the code that wrote to the data will be utterly confused by that. > Maybe you find it confusing because you're trying to reason about this > at the machine code level. Look at the source line level instead. I hope I explained above that on both levels we should see the same conceptual picture: a watchpoint always triggers _after_ the code was executed. By contrast, a breakpoint always triggers _before_ the code is executed. > If you watch foo, you should be told about watchpoint stops at lines > that touch foo. You should not be told about breaks in other lines. Again, this is mixing two subtly different aspects: one is where in the code was the instruction that wrote to the watched location, the other is where (i.e. at what PC) is the debuggee when we report the watchpoint. > If you hit at watchpoint in line 421, and you continue, and you had > defined a breakpoint in line 422, you would expect that breakpoint to > fire because 422 != 421. And if you continue, what instruction will be the first one to be executed, in your scheme? It cannot be the first instruction of line 422, since the breakpoint should have triggered before that. And it cannot be the last instruction of line 421, because that would trigger the same watchpoint again. And there's no instruction in between those two, so what can GDB do if we accept your views? The only thing it can do is not move at all, i.e. not resume the inferior, but instead generate a breakpoint event out of thin air. Is that what you are saying we should do?