From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3544 invoked by alias); 8 Apr 2006 08:23:13 -0000 Received: (qmail 3536 invoked by uid 22791); 8 Apr 2006 08:23:13 -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; Sat, 08 Apr 2006 08:23:10 +0000 Received: from farnswood.snap.net.nz (p202-124-114-176.snap.net.nz [202.124.114.176]) by viper.snap.net.nz (Postfix) with ESMTP id D0BF7751B72; Sat, 8 Apr 2006 20:23:05 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 207F262A99; Sat, 8 Apr 2006 09:22:48 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17463.29399.957570.820724@farnswood.snap.net.nz> Date: Sat, 08 Apr 2006 10:07:00 -0000 To: Eli Zaretskii Cc: drow@false.org, dirk.behme@googlemail.com, gdb@sourceware.org Subject: Re: MI return error changed from 6.3 to 6.4? In-Reply-To: References: <44368B51.1030707@gmail.com> <20060407160222.GA24731@nevyn.them.org> <17462.57160.545635.736634@farnswood.snap.net.nz> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00113.txt.bz2 ... > > Manual> This mechanism is provided as an aid to developers of GDB/MI > > Manual> clients and not as a reliable interface into the CLI. Since the > > Manual> command is being interpreteted in an environment that assumes > > Manual> GDB/MI behaviour, the exact output of such commands is likely to > > Manual> end up being an un-supported hybrid of GDB/MI and CLI output. > > > > so maybe we shouldn't fix it. > > Alternatively, we could leave what manual says as it is now, and fix > the code. Note that it says that _existing_ CLI commands are > accepted. So perhaps we should detect non-existing commands and > return an MI error indication. I seem to also recall that Andrew also said that using CLI through MI was a temporary arrangement (although I can't find that in the manual). > > On the other hand this was written before the command -interpreter-exec. > > If entering CLI commands directly (using -interpreter-exec implicitly) > > can be made as reliable as using -interpreter-exec explicitly, maybe this > > would be a convenient alternative, and the above paragraph could be > > removed from the manual. > > Such an incompatible change would require a quarantine period during > which the CLI support in MI is marked deprecated. What's incompatible? I mean in addition to, not instead of and here I'm suggesting the opposite i.e that CLI support in MI is not deprecated. My feeling is that -interpreter-exec *does* provide a reliable interface into the CLI while the hack that was used in GDB 6.3 didn't. I'm just saying that we may as well use it access CLI directly from MI. First though I think we should formally document the syntax of MI and CLI commands so that they don't get confused. CLI commands seem to always start with a lower case letter while MI commands start with "-" (I see TUI uses "-" to mean scroll backward). -- Nick http://www.inet.net.nz/~nickrob