From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8249 invoked by alias); 25 Sep 2004 00:44:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8242 invoked from network); 25 Sep 2004 00:44:20 -0000 Received: from unknown (HELO lakermmtao04.cox.net) (68.230.240.35) by sourceware.org with SMTP; 25 Sep 2004 00:44:20 -0000 Received: from white ([68.9.64.121]) by lakermmtao04.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040925004417.XMYZ17806.lakermmtao04.cox.net@white>; Fri, 24 Sep 2004 20:44:17 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CB0fi-0000sl-00; Fri, 24 Sep 2004 20:44:18 -0400 Date: Sat, 25 Sep 2004 00:44:00 -0000 From: Bob Rossi To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: MI changes Message-ID: <20040925004418.GA3379@white> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20040923123307.GA989@white> <4154A265.6090607@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4154A265.6090607@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-09/txt/msg00228.txt.bz2 On Fri, Sep 24, 2004 at 06:40:37PM -0400, Andrew Cagney wrote: > >Hi, > > > >Could I please have a response to this topic? I am being held up on the > >development of my project while waiting for this decision. > > I think others have already responded to this proposal with a clear > rationale for not making a change. We've already got numeric prefixes > which are returned with the command result. Asynchronous output has to > be self contained. Yes, I understand that numeric prefixes take account for the synchronous commands. However, what does the sentence "Asynchronous output has to be self contained" mean? I still think that the problem exists for asynchronous commands, and this is one of the reasons I brought the problem up. The big issue here that everyone seems to be avoiding is how we should deal with versioning of the MI commands. You yourself stated that GDB/MI should move to a versioning scheme where it is capable of working with front ends that are not tied to a particular version of GDB. It should also work with "snapshots" of GDB. This means that GDB should be self documenting at any given point about what type of MI output and MI input commands it receives/sends. Not just one big MI level. My recommendation to add the label's was a way for GDB to tell the front end what version of an MI output command it is sending. We could then add a new MI output command to GDB that tells the front end all of the capable MI output commands that the current version of the GDB your dealing with supports. The same could be true for MI input commands. Honestly, I don't think the current MI interface supports front ends that will work with multiple versions of GDB and I am trying to change that. I don't want to start hacking on CGDB until I know that it will work reasonably in several different environments, with several different version of GDB. If my solution isn't good, can we come up with some other suggestions? > >I propose several changes to MI. > > > > 1. Every MI output command is prefixed with a label saying what type > > of command it is. This is easy for synchronous commands. We will have > > to make a list of asynchronous MI output commands that can be > > documented some where. > > > > benefit: the front end knows how to deal with the data it was > > given in all circumstances > > > > 2. Because of this new label, all MI output commands of it's type > > will be backwards compatible. Only adding fields and such things are > > allowed. If it is necessary to change the command, a new MI command > > and label will be put in it's place. > > > > benefit: front ends will be very reliable because they will work > > with new and old GDB's. They will also work with snapshot of GDB > > instead of only major releases. > > > >BTW, this Email does not address MI input commands in any way. This will > >be the next step on my list. > > > >Thanks, > >Bob Rossi > >