From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13143 invoked by alias); 31 May 2009 16:34:09 -0000 Received: (qmail 13135 invoked by uid 22791); 31 May 2009 16:34:08 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 31 May 2009 16:34:03 +0000 Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id n4VGXx03005662 for ; Sun, 31 May 2009 17:34:00 +0100 Received: from gxk18 (gxk18.prod.google.com [10.202.11.18]) by wpaz24.hot.corp.google.com with ESMTP id n4VGXwxq018859 for ; Sun, 31 May 2009 09:33:58 -0700 Received: by gxk18 with SMTP id 18so11893539gxk.11 for ; Sun, 31 May 2009 09:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.54.6 with SMTP id c6mr2935424aga.108.1243787637988; Sun, 31 May 2009 09:33:57 -0700 (PDT) In-Reply-To: <200905301151.52892.pedro@codesourcery.com> References: <200905301151.52892.pedro@codesourcery.com> Date: Sun, 31 May 2009 16:34:00 -0000 Message-ID: Subject: Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] From: Doug Evans To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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: 2009-05/txt/msg00661.txt.bz2 On Sat, May 30, 2009 at 3:51 AM, Pedro Alves wrote: > Currently, with the generic framework, if GDB is attached to > multiple processes, issuing a "continue", "next", etc., makes GDB > resume all threads of all processes. =A0But, with the multi-forks > framework, GDB only debugs one of the forks at a given time, while > leaving the others stopped. Except in non-stop mode when "c -a" is required to continue all threads, "c" by itself just continues the current thread (right?). [And IWBN if there were a way to continue a subgroup of threads though I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"? I realize that's perhaps not ideal, but short of adding another command it's the first thing that came to me. :-) And no claim is made that this hasn't been discussed before ...] I wonder what the normal usage pattern will be of multiprocess debugging. An alternative to "set scheduler-multiple on|off" is to add another flag to the various commands. "scheduler-multiple" may be The Right Thing To Do, but adding more global state that controls command behaviour gives me pause ("exec-direction" anyone?). Another way to add scheduler-locking would have been to add options to "step", etc. "s -l" or some such ["l" for "locking" though "locking" out of place here, it's just an example anyway]. It's easier to script: # This isn't implementable today, it's just for illustration. define lstep set $save_scheduler_locking [get scheduler-locking] try step finally set scheduler-locking $save_scheduler_locking end end versus define lstep step -l end I'd be curious to hear what others think.