From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9718 invoked by alias); 5 Apr 2008 09:11:54 -0000 Received: (qmail 9710 invoked by uid 22791); 5 Apr 2008 09:11:53 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 05 Apr 2008 09:11:25 +0000 Received: from kahikatea.snap.net.nz (141.31.255.123.static.snap.net.nz [123.255.31.141]) by viper.snap.net.nz (Postfix) with ESMTP id EB4A03DA2BB; Sat, 5 Apr 2008 22:11:17 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 518528FC6D; Sat, 5 Apr 2008 21:10:54 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18423.16925.181684.296006@kahikatea.snap.net.nz> Date: Sat, 05 Apr 2008 17:20:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: linux native async mode support In-Reply-To: <200804041546.41673.ghost@cs.msu.su> References: <200803140810.22883.pedro@codesourcery.com> <18418.36774.469694.449649@kahikatea.snap.net.nz> <200804041546.41673.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 23.0.60.62 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: 2008-04/txt/msg00116.txt.bz2 > > The helper functions that you have written for common sequences are a good > > idea as they need only be updated in one place but the three here are the > > only ones of their kind (they output an extra "^done" over MI commands like > > -exec-next). Not really worth a dedicated helper function do you agree? > > Why there's extra "^done"? Presently, each command is supposed to have > either "^running" or "^done", not both. There's an extra "^done" because this is a CLI command entered in MI (and therfore case CLI_COMMAND: of captured_mi_execute_command). There are many issues here like should we diallow immediate use of CLI commands now and require explicit use of "-interpreter-exec console"? Then "-interpreter-exec console next" doesn't emit "(gdb)/n" after "^running" when in asynchronous mode, so should we remove it from synchronous mode too (as you have suggested)? But these are all MI issues and this test is meant to just be a mark in the sand for asynchronous mode, and one that I had lying around. For the moment, I don't really want to work on it further > I realize that fixing this requires > introducing "*running", so that we still know that the target is resumed. > I have the patch for *running basically done, so I suggest that I submit it, > and then we'll have just ^done in this example. I'm not sure what the output will look like after your change but it may still not be like normal MI output. > BTW, I'm not even sure that "^done" vs. "^running" + "^done" is so big > difference that a helper function cannot be introduced. The comment suggests that mi_gdb_test will not work but I have not revisited that since writing the test 18 months or so ago. If true, that could also make helper functions difficult. -- Nick http://www.inet.net.nz/~nickrob