From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27379 invoked by alias); 26 Mar 2008 03:23:11 -0000 Received: (qmail 27361 invoked by uid 22791); 26 Mar 2008 03:23:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 03:22:47 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m2Q3Mj5q007711 for ; Tue, 25 Mar 2008 20:22:45 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 20:22:44 -0700 Received: from [147.11.233.12] ([147.11.233.12]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 20:22:44 -0700 Message-ID: <47E9C183.9000901@windriver.com> Date: Wed, 26 Mar 2008 13:03:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <200803242016.19140.vladimir@codesourcery.com> <47E7F4D4.9050501@windriver.com> <47E81C22.4000508@windriver.com> <18409.25598.614328.93389@kahikatea.snap.net.nz> In-Reply-To: <18409.25598.614328.93389@kahikatea.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00235.txt.bz2 Defining thread sets for purpose of synchronized run control is an often requested feature in multi core debugging. IMO it would be easier for the MI client, if the "threadset" command would itself create a new thread id, which would then be selected with -thread-select. Cheers, Pawel Nick Roberts wrote: > >... > > > If a new feature is added to a particular command, such as the deferred > > > breakpoints, that single service can be replaced, updated, or extended > > > as needed. While adding an option across all commands forces changes in > > > all services. There is a command factory mechanism in CDI-GDB to > > > abstract some protocol changes which deals with small changes to > > > individual commands based on the protocol version, which DSF-GDB is > > > probably going to have to adopt as well. But this mechanism wouldn't be > > > necessary if the evolution in the protocol was more concerned with > > > backward compatibility, especially in a case like this where the > > > protocol change is not really necessary. > > > > Yes, I was thinking that a centralised entity that actually sends or > > creates command can easily add --thread option. > > I'm nnot sure exactly how it is proposed that non-stop mode should work but > rather than a --thread option, why not have a separate command that determines > which thread(s) the following commands would act on? Perhaps only the > execution commands, e.g run, next etc, would recognise this set. Using CLI > commands ;-) it could work something like this: > > (gdb) threadset 2-4 > > would mean that > > (gdb) continue& > > would resume threads 2, 3 and 4 > > Unlike operations like print, It doesn't seem necessary for these commands to > select the thread/frame first. > > Presumably you will be interested in implementing barrier points so there > could be further commands to hold and release threads, e.g., > > (gdb) hold 3 > > would mean that in the example above only threads 2 and 4 resumed > > (gdb) release 3 > > would allow it to run again. > > The command "threadset" on its own could show all the threads in the current > set and the commands "hold" and "release" on their own could show which threads > are currently held/released. > > For the current mode of operation, Gdb would give > > (gdb) threadset > all > (gdb) hold > none > (gdb) release > all > > This would then provide a backward compatible way to use all the MI > execution commands. > >