From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6236 invoked by alias); 7 May 2008 11:36:47 -0000 Received: (qmail 6139 invoked by uid 22791); 7 May 2008 11:36:46 -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; Wed, 07 May 2008 11:36:29 +0000 Received: (qmail 16610 invoked from network); 7 May 2008 11:36:27 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 May 2008 11:36:27 -0000 From: Pedro Alves To: "Pierre Muller" Subject: Re: [RFC] 09/10 Add "continue --all" Date: Wed, 07 May 2008 19:36:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200805061649.50105.pedro@codesourcery.com> <007a01c8b01b$68103f80$3830be80$@u-strasbg.fr> In-Reply-To: <007a01c8b01b$68103f80$3830be80$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805071236.25860.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-05/txt/msg00262.txt.bz2 A Wednesday 07 May 2008 09:21:53, Pierre Muller wrote: > I don't claim to understand this patch, > but I am still curious about one point: > > why do you use TARGET_SIGNAL_0 > in proceed_ptid, > while in non-stop mode, TARGET_SIGNAL_DEFAULT is used. > Because I copy&pasted it from somewhere else, and didn't notice that. :-) > If I understood correctly the code in > proceed function from infrun.c, > this would mean that in the non-stop mode with --all option, > even if stop_signal was set to a value > that is registered as "PASS", > stop_signal would be reset and > not passed to the inferior. > > > Isn't that a misbehavior? > Thanks! That's indeed a bug. > But anyway, should stop_signal become > a threadvar, in the sense that it should > be saved and restore in context_switch? > That's right. Not scritly command-per-thread related, but it was taken care of in patch 4. -- Pedro Alves