From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16294 invoked by alias); 2 Nov 2010 01:05:31 -0000 Received: (qmail 16282 invoked by uid 22791); 2 Nov 2010 01:05:30 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Nov 2010 01:05:26 +0000 Received: (qmail 1690 invoked from network); 2 Nov 2010 01:05:24 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Nov 2010 01:05:24 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix stale tp->step_resume_breakpoint Date: Tue, 02 Nov 2010 01:05:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: Jan Kratochvil References: <20101102004301.GA7972@host0.dyn.jankratochvil.net> In-Reply-To: <20101102004301.GA7972@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011020105.19217.pedro@codesourcery.com> 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: 2010-11/txt/msg00011.txt.bz2 On Tuesday 02 November 2010 00:43:01, Jan Kratochvil wrote: > A comment is welcome but it seems safe to me. I think this raises an obvious question, and hints at a larger issue: if you find you you need to tuck away step_resume_breakpoint, then, how come you don't need to do the same for all the other execution command state? (step_range_start, step_range_end, step_frame_id, continuations, etc.). I'd assume that in the use case you trip on step_resume_breakpoint troubles, you'd also be losing thread stepping state (or state for any other execution command), thus your thread would end up running free, forgetting about the previous command that was going on before the infcall. Is that not the case? -- Pedro Alves