From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13586 invoked by alias); 7 Oct 2004 18:50:13 -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 13552 invoked from network); 7 Oct 2004 18:50:11 -0000 Received: from unknown (HELO lakermmtao03.cox.net) (68.230.240.36) by sourceware.org with SMTP; 7 Oct 2004 18:50:11 -0000 Received: from white ([68.9.64.121]) by lakermmtao03.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041007185010.WIMM13098.lakermmtao03.cox.net@white>; Thu, 7 Oct 2004 14:50:10 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFdL8-0003tH-00; Thu, 07 Oct 2004 14:50:10 -0400 Date: Thu, 07 Oct 2004 19:44:00 -0000 From: Bob Rossi To: Felix Lee Cc: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041007185010.GD14573@white> Mail-Followup-To: Felix Lee , gdb@sources.redhat.com References: <20041007140455.GA14402@white> <20041007143716.GB14402@white> <20041007171240.65B25502AB6@stray.canids> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041007171240.65B25502AB6@stray.canids> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00230.txt.bz2 On Thu, Oct 07, 2004 at 10:12:40AM -0700, Felix Lee wrote: > 'Bob Rossi' : > > I understand that adding an MI command to the MI function set that can > > not be accessed by a front end that understands the MI protocol is > > nonsensical and confusing, that is why I am arguing on the side of not > > adding this command to the MI function set, but solving the problem > > another way. > > ... I'm lost. if I apply your statement to a different context, > you seem to be saying that gdb's "show version" command is a > nonsensical and confusing way of determining what version gdb is, > and there should be an out-of-band method of determining gdb > version. > > this seems to me obviously wrong, because there are many > situations where you're limited to serial communication with a > remote agent, so it isn't possible to get out-of-band > information. > > that situation is unlikely to happen with gdb itself, since in > any sane situation you're going to be able to invoke gdb with > arbitrary command switches. but that's unusual rather than > typical. most communication protocols need an in-band method of > determining protocol version. I am not sure when you say "out of band", if you are refering to GDB/MI's out of band record in the MI output syntax. I do understand what you are saying, and I agree with you. Some protocols allow for the version communication to take place within the protocol. This makes the most sense to me. For instance, XML allows the first line of the document to have the version number. From then on, it can use the correct parser to process the document. If the version number is not there, it can only guess at what's in the document, and errors can occcur. Basically, the version number is in a format the client can understand and then the client can choose the appropriate parser based off of this. I think adding an MI command to get the version is not the solution to this problem. Calling an MI command assumes that you already know the protocol, and then you can call the MI function. Otherwise, you are not necessarily handshaking, but you have to write the adhoc parser to get the information you need. For instance, if GDB supported 1 stable MI protocol, if it is an official release or a CVS snapshot, then the first thing GDB could output to the front end is the version of MI that it is communicating. If we wanted to be even more verbose, we could * define a syntax for an MI header that communicated to the front end all of the necessary things it would need to know before initializing it's protocol. * we could always handshake using the MI2 protocol, even though the protocol that GDB supports is a higher version. For option 2, this means that GDB would not necessarily support MI2, but it would handshake in that protocol, since it will probably never need to change for backward incompatibilities. This has the downside of forcing new front ends to be able to implement the MI2 protocol, which is probably not a good idea. Any comments? Thanks, Bob Rossi