From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15307 invoked by alias); 23 Mar 2008 07:38:56 -0000 Received: (qmail 15297 invoked by uid 22791); 23 Mar 2008 07:38:55 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 23 Mar 2008 07:38:38 +0000 Received: (qmail 26903 invoked from network); 23 Mar 2008 07:38:36 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Mar 2008 07:38:36 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [RFA] Implement -thread-info. Date: Sun, 23 Mar 2008 07:38:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com, Eli Zaretskii References: <200802171833.26673.vladimir@codesourcery.com> <20080226005822.GA3346@caradoc.them.org> <18405.58075.425704.501844@kahikatea.snap.net.nz> In-Reply-To: <18405.58075.425704.501844@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803231038.51044.vladimir@codesourcery.com> 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-03/txt/msg00338.txt.bz2 On Sunday 23 March 2008 07:55:55 Nick Roberts wrote: > Daniel Jacobowitz writes: > > On Tue, Feb 26, 2008 at 01:53:16PM +1300, Nick Roberts wrote: > > > + { "thread-info", { "info threads", 1 }, NULL, NULL }, > > > > I would suggest against using args_p == 1 for any new commands. > > The quoting rules between CLI and MI are different; we ignore that > > for some commands, but it's a bug and it bites frontend > > developers. > > > > If the arguments are just going to be integers then it doesn't > > make much difference but it will make things simpler if we want to > > add either quoted arguments or dashed options later. > > With non-stop mode there will presumably be many new MI commands. Just one, I think -- to enable non-stop mode. Many commands will take additional options, though. > Providing the same functionality in CLI duplicates a lot of effort. > Perhaps the parsing of MI and CLI arguments should be unified. Are you suggesting that we continue to implement MI commands by basically executing the corresponding CLI command? - Volodya