From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13513 invoked by alias); 5 Apr 2002 15:54:11 -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 13434 invoked from network); 5 Apr 2002 15:54:10 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 5 Apr 2002 15:54:10 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16tW2b-0003vt-00; Fri, 05 Apr 2002 10:54:17 -0500 Date: Fri, 05 Apr 2002 07:54: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: <20020405105416.A14105@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6480-Fri05Apr2002103430+0300-eliz@is.elta.co.il> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00159.txt.bz2 On Fri, Apr 05, 2002 at 10:34:30AM +0300, Eli Zaretskii wrote: > > Date: Tue, 2 Apr 2002 18:43:33 -0500 > > From: Daniel Jacobowitz > > > > When I tried it I got stuck > > on the bp_shlib_event breakpoint. We would hit it, remove, single-step > > (trap expected), check where we were... and find ourselves at the > > shared library breakpoint again because of DECR_PC_AFTER_BREAK! > > > > Instead, I now collect only non-breakpoint events. > > 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. I don't really think it's any more ad-hoc than the trap_expected flag. If trap_expected is set, then we expected to stop on the next instruction because of some property of (either single-stepping or) that instruction. Breakpoints are also a property of that instruction; so we ignore them when checking for any other interesting reason to have stopped. Watchpoints, on the other hand, are clearly different. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer