From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31337 invoked by alias); 15 Nov 2008 16:11:17 -0000 Received: (qmail 31262 invoked by uid 22791); 15 Nov 2008 16:11:16 -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; Sat, 15 Nov 2008 16:10:25 +0000 Received: (qmail 17494 invoked from network); 15 Nov 2008 16:10:22 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Nov 2008 16:10:22 -0000 From: Pedro Alves To: "Ulrich Weigand" Subject: Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode Date: Sat, 15 Nov 2008 21:30:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, drow@false.org References: <200811142104.mAEL4JBX024219@d12av02.megacenter.de.ibm.com> In-Reply-To: <200811142104.mAEL4JBX024219@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811151610.40427.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: 2008-11/txt/msg00386.txt.bz2 On Friday 14 November 2008 21:04:18, Ulrich Weigand wrote: > a while ago I posted a patch to fix problem PR 2250: > http://sourceware.org/ml/gdb-patches/2008-05/msg00089.html > > This problem is about the behaviour of GDB when single-stepping > a thread of a multi-threaded application. If during a single-step > operation, some other event happens in another thread, GDB may get > into an inconsistent state, where some internal data structures > still think a single-step operation is going on, while this is > in fact no longer true. > > The patch I originally proposed, however, conflicted with the > new non-stop mode (where single-step operations can be outstanding > in multiple threads at the same time), so it was never applied. > Now that all the non-stop code is in mainline, the original bug > is still present in the all-stop mode. I've reworked the patch > to fix the problem in all-stop mode, while keeping the new behaviour > in non-stop mode unchanges. Thank you very much for your patience and for refitting the patch. I do find this version much cleaner than the last (for not relying on global variables, and due to context-switching being a thing of the past). > > As discussed in the message refered to above, I'm implementing the > the following two changes: > > - If the step operation is interrupted by an *internal* breakpoint > that is handled transparently, the operation continues in a > transparent and consistent manner after the breakpoint was handled. > (This is the handle_inferior_event change in the patch below.) > I still agree with this behaviour. I've made it so that GDB removes step-resume breakpoints of all threads (in all-stop) on a normal_stop for the same reasoning (delete_step_thread_step_resume_breakpoint). > - If the step operation is interrupted by an *explicit* breakpoint > that breaks to a user prompt, it is completely cancelled. It is > then up to the user how to continue from the prompt. > (This is the clear_proceed_status change in the patch below.) Yay! I had something similar here to address this bullet (updated from the last time I showed it, but unfinished and a bit hacky) that I ended up never submitting. Yours is better. > Regression tested on powerpc64-linux. This patch fixes the problem > originally reported as PR 2250 (thanks to Emi Suzuki for verifying!). > > I didn't test anything with all-stop mode, but by construction the > patch should not modify the behaviour at all in this case. Yeah, should be fine (obviously talking about non-stop mode here). > Does this look right? If there are no objections, I'm planning > on committing this in a couple of days. I like this a lot. Hmm, speaking of things that aren't cleared properly in all threads when we are going to start a proceed, shouldn't the things cleared in init_thread_stepping_state be cleared in clear_proceed_status_thread instead? E.g., step_after_step_resume_breakpoint, etc. -- Pedro Alves