From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4052 invoked by alias); 17 Nov 2008 20:31:10 -0000 Received: (qmail 3973 invoked by uid 22791); 17 Nov 2008 20:31:10 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Nov 2008 20:30:08 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id mAHKU51H091216 for ; Mon, 17 Nov 2008 20:30:05 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAHKU52G1552458 for ; Mon, 17 Nov 2008 21:30:05 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAHKU5Zo002484 for ; Mon, 17 Nov 2008 21:30:05 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id mAHKU54d002481; Mon, 17 Nov 2008 21:30:05 +0100 Message-Id: <200811172030.mAHKU54d002481@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 17 Nov 2008 21:30:05 +0100 Subject: Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode To: pedro@codesourcery.com (Pedro Alves) Date: Tue, 18 Nov 2008 01:43:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, drow@false.org In-Reply-To: <200811171948.33905.pedro@codesourcery.com> from "Pedro Alves" at Nov 17, 2008 07:48:33 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00444.txt.bz2 Pedro Alves wrote: > 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). I agree that random_signal need not survive beyond a handling of a single event. In fact, I think random_signal should probably simply be a local variable of handle_inferior_event; it's not accessed anywhere else. In fact other members of the ecs struct should probably be local variables, maybe some of them passed explicitly to subroutines. I think this would help simplify understanding the data-flow along handle_inferior_event and its subroutines ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com