From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29104 invoked by alias); 26 Nov 2007 18:51:41 -0000 Received: (qmail 29096 invoked by uid 22791); 26 Nov 2007 18:51:40 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 18:51:35 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id C71E13BFB5; Mon, 26 Nov 2007 10:29:58 -0800 (PST) Subject: Re: [RFA] Don't ignore consecutive breakpoints. From: Michael Snyder To: Vladimir Prus Cc: gdb-patches@sources.redhat.com In-Reply-To: <200711232310.17854.vladimir@codesourcery.com> References: <200711232310.17854.vladimir@codesourcery.com> Content-Type: text/plain Date: Mon, 26 Nov 2007 18:51:00 -0000 Message-Id: <1196102361.2501.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00491.txt.bz2 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? Thanks, Michael