From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21777 invoked by alias); 29 Nov 2007 11:27:17 -0000 Received: (qmail 21769 invoked by uid 22791); 29 Nov 2007 11:27:17 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 Nov 2007 11:27:12 +0000 Received: (qmail 29339 invoked from network); 29 Nov 2007 11:27:10 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Nov 2007 11:27:10 -0000 From: Vladimir Prus To: Michael Snyder Subject: Re: [RFA] Don't ignore consecutive breakpoints. Date: Thu, 29 Nov 2007 11:27:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <200711232310.17854.vladimir@codesourcery.com> <1196102361.2501.22.camel@localhost.localdomain> In-Reply-To: <1196102361.2501.22.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711291427.06044.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00543.txt.bz2 On Monday 26 November 2007 21:39:21 Michael Snyder wrote: > On Fri, 2007-11-23 at 23:10 +0300, Vladimir Prus wrote: > > Suppose we have two breakpoints at two consecutive > > addresses, and we do "step" while stopped on the > > first breakpoint. GDB testsuite has a test (consecutive.exp) > > that the second breakpoint will be hit a reported, and the > > Yeah, I was the author of that test, back in 2001. > Several years and several employers ago, but I think > I am able to remember a little about the context. > > > test passes, but the code directly contradicts, saying: > > > > /* Don't even think about breakpoints if just proceeded over a > > breakpoint. */ > > if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected) > > { > > if (debug_infrun) > > fprintf_unfiltered (gdb_stdlog, "infrun: trap expected\n"); > > bpstat_clear (&stop_bpstat); > > } > > > > what's happening is that we indeed ignore the breakpoint, and try > > to step further. However ecs->another_trap is not set, so we step > > with breakpoints inserted, and immediately hit the now-inserted > > breakpoint. Therefore, I propose to remove that code. > > > > On x86, the below patch causes a single test outcome change: > > > > -KFAIL: gdb.base/watchpoint.exp: next after watch x (PRMS: gdb/38) > > +PASS: gdb.base/watchpoint.exp: next after watch x > > Yeah, the problem is that you have only tested x86 architecture, > and what I think I recall is that this test was for software > single-step. > > You have to be aware that you have just single-stepped, so that > you interpret the trap instruction under the PC as related to > stepping. If you have two consecutive BP-related traps, and you > try to single step over one of them, you may miss the second one > because you believe it to be only a single-stepping trap. > > Can you test your patch on an architecture that uses software SS? I've tested on arm-linux/qemu, which uses software single-step, and got no regressions. Looking again at the patch, the code fragment I'm changing has two side-effects: - Setting ecs->random_signal - Setting stop_bpstat My patch has no effect on the way ecs->random_signal is set. However, in the case when we've just single-stepped over breakpoint, the original code will clear stop_bpstat, and in my patch, it would be set. We will immediately report report the hit of the consecutive breakpoint. Since we don't set ecs->another_trap, the trap_expected variable will be reset to 0 when we resume. So, is the patch OK? - Volodya - Volodya