From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16953 invoked by alias); 7 May 2008 08:22:23 -0000 Received: (qmail 16935 invoked by uid 22791); 7 May 2008 08:22:22 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 May 2008 08:22:01 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m478Lt9i035607 ; Wed, 7 May 2008 10:21:55 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402::142]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m478LsZm014376 ; Wed, 7 May 2008 10:21:54 +0200 (CEST) Received: from d620muller (laocoon.u-strasbg.fr [130.79.112.72]) by mailserver.u-strasbg.fr (8.13.8/jtpda-5.5pre1) with ESMTP id m478Lp37062577 ; Wed, 7 May 2008 10:21:54 +0200 (CEST) From: "Pierre Muller" To: "'Pedro Alves'" , References: <200805061649.50105.pedro@codesourcery.com> In-Reply-To: <200805061649.50105.pedro@codesourcery.com> Subject: RE: [RFC] 09/10 Add "continue --all" Date: Wed, 07 May 2008 11:58:00 -0000 Message-ID: <007a01c8b01b$68103f80$3830be80$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::157]); Wed, 07 May 2008 10:21:55 +0200 (CEST) X-Virus-Status: Clean 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/msg00258.txt.bz2 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. If I understood correctly the code in=20 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. =20=20 Isn't that a misbehavior? But anyway, should stop_signal become a threadvar, in the sense that it should be saved and restore in context_switch? Pierre Muller Pascal language support maintainer for GDB -----Message d'origine----- De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.= org] De la part de Pedro Alves Envoy=C3=A9 : Tuesday, May 06, 2008 5:50 PM =C3=80 : gdb-patches@sourceware.org Objet : [RFC] 09/10 Add "continue --all" In non-stop mode, exec commands apply only to the current thread. We can add a mechanism to resume all threads. In a frontend perpective, I'= m not clear if we should implement -exec-continue --all, -exec-continue --t= hread=3D"all", or just require the frontend to do the: for each thread in stopped threads resume thread done In CLI, "thread apply all continue&" works too, but it feels to longuish t= o type? Opinions? Import mi-getopt into common code and use it in CLI? -- Pedro Alves