From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5085 invoked by alias); 30 Nov 2007 10:04:02 -0000 Received: (qmail 5069 invoked by uid 22791); 30 Nov 2007 10:03:58 -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; Fri, 30 Nov 2007 10:03:53 +0000 Received: (qmail 13152 invoked from network); 30 Nov 2007 10:03:52 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Nov 2007 10:03:52 -0000 From: Vladimir Prus To: Michael Snyder Subject: Re: [RFA] Don't ignore consecutive breakpoints. Date: Fri, 30 Nov 2007 10:04:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <200711232310.17854.vladimir@codesourcery.com> <200711291427.06044.vladimir@codesourcery.com> <1196385275.2501.146.camel@localhost.localdomain> In-Reply-To: <1196385275.2501.146.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711301303.45966.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/msg00561.txt.bz2 On Friday 30 November 2007 04:14:35 Michael Snyder wrote: > > > 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? > > Thanks for the testing and analysis. > I have no further objection. Thanks, checked in. - Volodya