From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4868 invoked by alias); 25 Mar 2008 20:44:26 -0000 Received: (qmail 4856 invoked by uid 22791); 25 Mar 2008 20:44:26 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Mar 2008 20:44:00 +0000 Received: from kahikatea.snap.net.nz (2.28.255.123.static.snap.net.nz [123.255.28.2]) by viper.snap.net.nz (Postfix) with ESMTP id 675063DA23F; Wed, 26 Mar 2008 09:43:56 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 512D38FC6D; Wed, 26 Mar 2008 08:43:43 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18409.25598.614328.93389@kahikatea.snap.net.nz> Date: Tue, 25 Mar 2008 21:28:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <200803242016.19140.vladimir@codesourcery.com> <47E7F4D4.9050501@windriver.com> <47E81C22.4000508@windriver.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 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/msg00231.txt.bz2 >... > > 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. -- Nick http://www.inet.net.nz/~nickrob