From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3590 invoked by alias); 4 Oct 2004 21:07:28 -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 3203 invoked from network); 4 Oct 2004 21:07:27 -0000 Received: from unknown (HELO lakermmtao11.cox.net) (68.230.240.28) by sourceware.org with SMTP; 4 Oct 2004 21:07:27 -0000 Received: from white ([68.9.64.121]) by lakermmtao11.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041004210726.BDVQ27578.lakermmtao11.cox.net@white>; Mon, 4 Oct 2004 17:07:26 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CEa3K-0002Lo-00; Mon, 04 Oct 2004 17:07:26 -0400 Date: Mon, 04 Oct 2004 21:12:00 -0000 From: Bob Rossi To: Jason Molenda Cc: Felix Lee , gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041004210726.GA8846@white> Mail-Followup-To: Jason Molenda , Felix Lee , gdb@sources.redhat.com References: <62E49A52-1639-11D9-8F59-000A9569836A@canids.net> <20041004122439.A4660@molenda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041004122439.A4660@molenda.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00062.txt.bz2 On Mon, Oct 04, 2004 at 12:24:39PM -0700, Jason Molenda wrote: > On Mon, Oct 04, 2004 at 11:12:01AM -0700, Felix Lee wrote: > > Bob Rossi : > > > With the information I have now, here is the problem. A snapshot of GDB > > > will say that it is at MI4, although, it is really at some > > > developmental version. > > > > does that ever happen? if gdb says it supports MI4 but it > > doesn't really, then it's lying, and that's a bug. > > For what it's worth, Bob does have a point here. > > When an incompatible change to MI is made, the version # is bumped. > >From that point in time until the new MI version is "finalized", > it's usually a free-for-all to add whatever changes you want into > the new MI version. > > I don't know if there's an official way of telling whether a > particular MI version has been finalized -- personally, I think of > the highest MI version as being the in-development one, which is > subject to change. > > I don't really agree with the problem Bob is pointing out, > personally. If I were writing a front end, I'd target the > highest stable version I can rely on (these days that would > be MI2), and use that. Or if I didn't really need the changes > in MI2, I'd target MI1. Yes yes, of course I am going to try to target the highest protocol that the current GDB supports. The first implementation I write will be MI2. The whole point of this thread is basically to figure out from GDB what the highest stable protocol of MI that it supports is, and use it. I want to be able to determine this even if GDB is not an official release, but just a CVS snapshot. > I do see some legitimate problems that Bob is raising. > > 1. I don't know of an official way to tell if an MI command set > has been finalized. The policy I outlined above -- the highest > # MI command set is in development, until the version # is bumped -- > is my own understanding, but it might be wrong. I basically need from GDB all of the MI versions that it supports. This list should not include a development version of the MI protocol, that is currently being worked on. If you have a CVS snapshot you currently have no way of knowing that the highest MI protocol number is a development version, and not an official release. > 2. There isn't any way for a front end developer to tell exactly > what the MI differences are without looking at the source. I > know old gdb releases' documentation should make this clear, > but I'd be surprised if it's really clear enough to write an > implementation from. This is true, I would already have a hard time write an MI protocol implementation. I really think at least having the differences from the last protocol would be a big help. At least that way, I could start with MI3, and then when MI4 comes around, I could see a list of incompatibilites. The real answer to me would be to have a list of all the MI protocols documented in every release. Especially since they are backwards compatible, and GDB still supports them. Maybe things like have the MI commands list what version of MI they appeared in. > 3. Is there a guarantee that old MI interfaces will be supported? > Or will we wake up to find gdb 6.3 has deprecated, e.g. MI1, and > scheduled it for purging? This is what I need to know. Thanks, Bob Rossi