From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29735 invoked by alias); 1 Jun 2009 15:55:58 -0000 Received: (qmail 29724 invoked by uid 22791); 1 Jun 2009 15:55:56 -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; Mon, 01 Jun 2009 15:55:47 +0000 Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id n51FtgvR030409 for ; Mon, 1 Jun 2009 16:55:43 +0100 Received: from gxk20 (gxk20.prod.google.com [10.202.11.20]) by wpaz9.hot.corp.google.com with ESMTP id n51FteEp031669 for ; Mon, 1 Jun 2009 08:55:41 -0700 Received: by gxk20 with SMTP id 20so693109gxk.6 for ; Mon, 01 Jun 2009 08:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.93.8 with SMTP id q8mr5397822agb.13.1243871740740; Mon, 01 Jun 2009 08:55:40 -0700 (PDT) In-Reply-To: <200905312307.03257.pedro@codesourcery.com> References: <200905301151.52892.pedro@codesourcery.com> <200905312307.03257.pedro@codesourcery.com> Date: Mon, 01 Jun 2009 15:55: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: tromey@redhat.com, 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-06/txt/msg00008.txt.bz2 On Sun, May 31, 2009 at 3:07 PM, Pedro Alves wrote: > Re. 'c -t 1 2 3', and similars, you're skipping a lot of ground. Whoa. Apologies for putting you through all that typing :-(. It was just an off-the-cuff example and was certainly *not* aimed at all-stop. > Non-stop, however, avoids all these issues by working on top > of an asynchronous target interface. Indeed. > My patch simply attempts at making all-stop multi-inferior behave > the same as multi-forks + all-stop worked ever since it was added, so > that we can continue lifting gdb's age old single-inferior design > restrictions. =A0E.g., trying to resume all forks is still a very > limited experience, since GDB will only insert breakpoints in one > of the forks... =A0DICOS doesn't have this issue (breakpoints are visible > to all processes), so resuming all inferiors is a feature that I can > claim is useable today on some targets. > > I'm not saying that we should stick to this new switch forever, but > IMNSHO, making gdb a parallel debugger inevitably takes experimentation > and user feedback (this is nothing new: we can consider the multi-forks > the first experimentation). I guess I'm a bit confused (no claim is made that that's unexpected :-)). I was offering an alternative. I'd still like to hear what you think of adding a modifier to "continue", etc. instead. I'm not wedded to it of course. In part it seemed like a good time to talk about the two alternatives.