From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10284 invoked by alias); 6 Apr 2002 15:36:16 -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 10277 invoked from network); 6 Apr 2002 15:36:15 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 6 Apr 2002 15:36:15 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16tsEn-0003G9-00; Sat, 06 Apr 2002 10:36:21 -0500 Date: Sat, 06 Apr 2002 07:36: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: <20020406103621.A12359@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> <20020405120851.A17113@nevyn.them.org> <4331-Sat06Apr2002104144+0300-eliz@is.elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4331-Sat06Apr2002104144+0300-eliz@is.elta.co.il> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00220.txt.bz2 On Sat, Apr 06, 2002 at 10:41:45AM +0300, Eli Zaretskii wrote: > > 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. You can't anyway. You break before an instruction is executed and watchpoint before the next instruction is executed, right? > > 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? Well, I set the ignore breakpoints flag in the caller only if we are stepping. > > 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? No. In my original message I made a comment about shlib_event breakpoints being a problem. Other breakpoints would to. This is all because of the "watchpoint after instr, breakpoint before" thing - we would still have to deal with this, or we'd just keep hitting the same breakpoint over and over if there was a watchpoint on the next instruction. > > [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. That too. But something more fundamental is wrong, because we never stop -at all-. I remember something involving initializing the watchpoint registers... > > > 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. > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer