From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20271 invoked by alias); 17 Nov 2008 19:48:42 -0000 Received: (qmail 20229 invoked by uid 22791); 17 Nov 2008 19:48:42 -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; Mon, 17 Nov 2008 19:48:07 +0000 Received: (qmail 24349 invoked from network); 17 Nov 2008 19:48:05 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Nov 2008 19:48:05 -0000 From: Pedro Alves To: "Ulrich Weigand" Subject: Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode Date: Mon, 17 Nov 2008 23:36:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, drow@false.org References: <200811171856.mAHIuMHs011334@d12av02.megacenter.de.ibm.com> In-Reply-To: <200811171856.mAHIuMHs011334@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: <200811171948.33905.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/msg00441.txt.bz2 On Monday 17 November 2008 18:56:22, Ulrich Weigand wrote: > B.t.w. what about init_execution_control_state? This seems to > be nowhere called ... Hmm, good catch. It seems that got left behind when I pulled all that was context-switched out of struct execution_control_state (which is now a bit mis-named). There used to be a call to init_execution_control_state in wait_for_inferior around where now there's a memset, so we're not missing anything (clearing ecs->random_signal). I don't think there's any reason to keep random_signal untouched across handle_inferior_event invocations in the while (1) loop in wait_for_inferior ? --- handle_inferior_event seems to set or clear it itself before relying on its value, but I wouldn't be that surprised there's a weird twisted code path where that isn't happening, and we could be reading a random_signal from a previous stop. Maybe moving the memset to inside the while (1) loop in wait_for_inferior would make things a bit clearer (if my reasoning about random_signal not being needed across events is correct). -- Pedro Alves