From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15987 invoked by alias); 5 Apr 2002 17:08:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15980 invoked from network); 5 Apr 2002 17:08:45 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 5 Apr 2002 17:08:45 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16tXCl-0004ca-00; Fri, 05 Apr 2002 12:08:51 -0500 Date: Fri, 05 Apr 2002 09:08:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint Message-ID: <20020405120851.A17113@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: <20020402184333.A8464@nevyn.them.org> <6480-Fri05Apr2002103430+0300-eliz@is.elta.co.il> <20020405105416.A14105@nevyn.them.org> <9743-Fri05Apr2002194115+0300-eliz@is.elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9743-Fri05Apr2002194115+0300-eliz@is.elta.co.il> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00169.txt.bz2 On Fri, Apr 05, 2002 at 07:41:16PM +0300, Eli Zaretskii wrote: > > Date: Fri, 5 Apr 2002 10:54:16 -0500 > > From: Daniel Jacobowitz > > > > > > Isn't this a bit ad hoc? I think the issue of doing TRT when both a > > > breakpoint and a watchpoint fire for the same instruction needs a more > > > general solution. While ignoring breakpoints might be the Right Thing > > > in this particular case, I wonder what will be TRT in other cases? > > > > > > Did you try to arrange for a normal breakpoint and a watchpoint on the > > > same instruction, and see what happens in that case, with and without > > > this patch? > > > > Yes, I did - that's 'watch a.x' in gdb.c++/annota2.exp. Without the > > patch it fails on i386-linux, with it it passes. > > ``Fails'' and ``passes'' are in the eyes of the beholder ;-) > > I mean, I'm not even sure what is the ``right'' behavior in this case. > The annota2.exp test expects something very specific, but is that what > we want? Perhaps GDB should say that both breakpoint and watchpoint > fired instead, or do something else? > > I'd suggest to discuss this a bit, because otherwise I don't even know > what are the criteria for approving or rejecting the patch. The mere > fact that the number of testsuite failures goes down is not enough, > IMHO. I think GDB ought to show that both the breakpoint and watchpoint have fired. At least, that's the behavior I would expect. I also thought that was what it would do, but I can't seem to make that happen. Barring that, I personally believe that watchpoints should trump breakpoints; if you stop at a line and have a breakpoint there, you know you hit the breakpoint. GDB should tell you if you are stopping for another reason. Also bear in mind that if you have this sequence: - write to x - other instruction <--- breakpoint here You will stop based on the watchpoint, because the watchpoint happens first. You'll get a trap just before you would have hit the breakpoint. GDB handles this OK, and does report the watchpoint. It's only if we expected a trap (single stepping for instance) that this does not work. The current failure is "single step over something which triggers the watchpoint, landing on something with a breakpoint". Without my patch, we detect that we are at an address with a breakpoint, and don't even try to check our watchpoints. [In fact, I'm having a great deal of trouble with hardware watchpoints surviving re-running. Remember that conversation from several months ago? var.c: int x; int main () { x = 0; x = 1; x = 2; return x; } (gdb) watch x Hardware watchpoint 1: x (gdb) r Starting program: /home/drow/debugging/stabrel/foo/foo Hardware watchpoint 1: x Hardware watchpoint 1: x Hardware watchpoint 1: x Old value = 0 New value = 1 main () at var.c:8 8 x = 2; (gdb) c Continuing. Hardware watchpoint 1: x Old value = 1 New value = 2 main () at var.c:9 9 return x; (gdb) Continuing. Program exited with code 02. (gdb) r Starting program: /home/drow/debugging/stabrel/foo/foo Hardware watchpoint 1: x Hardware watchpoint 1: x Program exited with code 02. First of all, it stops the instruction after where I would expect. That's probably my expectations being off, however. More important is the fact that it doesn't stop at all if I re-run. I'll look into this (at least a testcase...).] > > > I don't really think it's any more ad-hoc than the trap_expected flag. > > Perhaps not, but that doesn't mean we should proliferate ad-hoc'ery. > > More importantly, an introduction of a general-purpose mechanism to > ignore breakpoints is something that I consider to be dangerous, > because it is no longer limited to special situations such as > single-stepping. Well, we could just as easily call the flag "single_stepping"... That would probably limit abuse. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer