From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2410 invoked by alias); 26 Nov 2007 19:00:11 -0000 Received: (qmail 2394 invoked by uid 22791); 26 Nov 2007 19:00:10 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 18:59:59 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IwjBE-0001ZU-Cc for gdb-patches@sources.redhat.com; Mon, 26 Nov 2007 18:59:40 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 18:59:40 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 18:59:40 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [RFA] Don't ignore consecutive breakpoints. Date: Mon, 26 Nov 2007 19:00:00 -0000 Message-ID: References: <200711232310.17854.vladimir@codesourcery.com> <1196102361.2501.22.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 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/msg00492.txt.bz2 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? Sure, I'll test it on arm, which uses software single step. Given that Ulrich reports software single step breakage from my other patch, it seems like software single step is an important variable that I did not test :-( Thanks, Volodya