From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15252 invoked by alias); 6 Apr 2002 07:48:20 -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 15245 invoked from network); 6 Apr 2002 07:48:16 -0000 Received: from unknown (HELO heimdall.inter.net.il) (192.114.186.17) by sources.redhat.com with SMTP; 6 Apr 2002 07:48:16 -0000 Received: from zaretsky (diup-217-58.inter.net.il [213.8.217.58]) by heimdall.inter.net.il (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id BHI32875; Sat, 6 Apr 2002 10:46:17 +0300 (IDT) Date: Fri, 05 Apr 2002 23:48:00 -0000 From: "Eli Zaretskii" To: drow@mvista.com Message-Id: <4331-Sat06Apr2002104144+0300-eliz@is.elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <20020405120851.A17113@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 5 Apr 2002 12:08:51 -0500) Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint Reply-to: Eli Zaretskii 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> <20020405120851.A17113@nevyn.them.org> X-SW-Source: 2002-04/txt/msg00215.txt.bz2 > Date: Fri, 5 Apr 2002 12:08:51 -0500 > From: Daniel Jacobowitz > > 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. Try using a hardware-assisted breakpoint, not a normal breakpoint. Since the latter works by replacing the instruction with a breakpoint opcode, you cannot have a breakpoint and a watchpoint at exactly the same PC value, because doing so replaces the instruction that's supposed to write into some data with the breakpoint opcode. > 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. That's okay, since the instruction that writes to x is before the breakpoint. In this case, I'd expect to have a watchpoint, then, when I continue, I'd expect to hit the breakpoint. > It's only if we expected a trap (single stepping for instance) that > this does not work. If this is limited to stepping, can we check whether we are stepping instead of (or in addition to) the test for whether to ignore breakpoints? > Without my patch, we detect that we are at an address with a > breakpoint, and don't even try to check our watchpoints. If we change GDB to report both the breakpoint and watchpoint, the problem would go away, no? > [In fact, I'm having a great deal of trouble with hardware watchpoints > surviving re-running. Remember that conversation from several months > ago? Yes. This is definitely wrong behavior, IMHO. IIRC, the problem is that GDB doesn't initialize the ``old value'' correctly on the rerun, and so when the watchpoint hits, it thinks it's a false positive, because watchpoints are suppressed if the watched value doesn't change. > > 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. If all else fails, at least that, yes.