From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8661 invoked by alias); 31 May 2009 22:06:43 -0000 Received: (qmail 8652 invoked by uid 22791); 31 May 2009 22:06:42 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 31 May 2009 22:06:38 +0000 Received: (qmail 8521 invoked from network); 31 May 2009 22:05:34 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 May 2009 22:05:34 -0000 From: Pedro Alves To: tromey@redhat.com Subject: Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] Date: Sun, 31 May 2009 22:06:00 -0000 User-Agent: KMail/1.9.10 Cc: Doug Evans , gdb-patches@sourceware.org References: <200905301151.52892.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905312307.03257.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: 2009-05/txt/msg00671.txt.bz2 On Sunday 31 May 2009 19:29:19, Tom Tromey wrote: > >>>>> "Doug" == Doug Evans writes: > > Doug> [And IWBN if there were a way to continue a subgroup of threads though > Doug> I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"? I > Doug> realize that's perhaps not ideal, but short of adding another command > Doug> it's the first thing that came to me. :-) And no claim is made that > Doug> this hasn't been discussed before ...] > > Yeah, I think this is the "itset" idea that Stan mentioned and that > Pedro referred to (IIUC) as being totalview-like: > > http://sourceware.org/ml/gdb/2008-08/msg00169.html Yes, sort of. itsets as stan described are just basically HPD's ptsets: http://sourceware.org/frysk/documentation/hpd.pdf In fact, a lot of what's described in Stan's spec is HPD influenced. Totalview has similar concepts, and, it also has concept of something like dynamic thread control groups. See: http://www.totalviewtech.com/support/documentation/totalview/index.html Using Threads Processes and Threads Types of Threads Organizing Chaos Note that given that non-stop controls threads individually, these groups *can be implemented on the frontend side*, so this isn't really *the* high priority to me. Yes, I do think it is a nice feature to have on the cli as well. > > (The wiki should link to this note IMO... perhaps I will edit it in.) Sure, go ahead. > > Doug> I wonder what the normal usage pattern will be of multiprocess debugging. > > Doug> An alternative to "set scheduler-multiple on|off" is to add another > Doug> flag to the various commands. > Doug> "scheduler-multiple" may be The Right Thing To Do, but adding more > Doug> global state that controls command behaviour gives me pause > Doug> ("exec-direction" anyone?). > > I agree. Global settings seem particularly user-unfriendly when > debugging multiple inferiors. E.g., what if you want to reverse-debug > one inferior but none of the others? I suppose you can make the > settings per-inferior. But this also seems to have potential for a > lot of user confusion. > > Doug> Another way to add scheduler-locking would have been to add > Doug> options to "step", etc. "s -l" or some such ["l" for "locking" > Doug> though "locking" out of place here, it's just an example > Doug> anyway]. > > Yeah. Re. 'c -t 1 2 3', and similars, you're skipping a lot of ground. The current all-stop design is very limited run-control wise, and doesn't allow all those sorts of things. E.g., the current target_resume interface (and all the proceed/resume design) is limited in that you have to tell the target what you want to resume in only a single call (think remote protocol vCont --- as soon as you tell the target to resume whatever, the target won't accept any other commands until something stops). I've mentioned before that gdb's resume interface would probably benefit from reusing gdb's gdbserver target_resume interface ideas. We'd probably need to implement support for "held threads" as well, which by itself is a good idea in the long run. This is all a non-short amount of work. Non-stop, however, avoids all these issues by working on top of an asynchronous target interface. Unfortunatelly, I haven't seen any effort in making all targets implement asynchronous interfaces, or fixing the known async issues. Until someone tackles those items, we can't think of adding those "s -t 1 2 3"'s in all-stop. non-stop is a different issue. 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. E.g., trying to resume all forks is still a very limited experience, since GDB will only insert breakpoints in one of the forks... DICOS 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). -- Pedro Alves