From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11533 invoked by alias); 4 Oct 2004 19:24:40 -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 11523 invoked from network); 4 Oct 2004 19:24:39 -0000 Received: from unknown (192.220.74.81) by sourceware.org with QMTP; 4 Oct 2004 19:24:39 -0000 Received: (qmail 9927 invoked by uid 19025); 4 Oct 2004 19:24:39 -0000 Date: Mon, 04 Oct 2004 19:54:00 -0000 From: Jason Molenda To: Felix Lee Cc: gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041004122439.A4660@molenda.com> References: <62E49A52-1639-11D9-8F59-000A9569836A@canids.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <62E49A52-1639-11D9-8F59-000A9569836A@canids.net>; from felix.1@canids.net on Mon, Oct 04, 2004 at 11:12:01AM -0700 X-SW-Source: 2004-10/txt/msg00056.txt.bz2 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. 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. 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. 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? Realistically, the changes to MI are not dramatic; they're almost always additions that can be ignored if the front end wasn't expecting them -- that was the whole point of the MI output design. The most obvious break was mi0 vs mi1, but that was a long time ago. On the other hand, the reason the MI interface has been so stable is (IMHO) because there are so few shipping FEs that use it. Apple has one, and we've got quite a large number of changes in the MI. I understand Eclipse is now using it -- the resurgance of work on the FSF gdb MI interface these past couple years is the evidence of that. As more FEs start using MI, I expect there to be more changes, or at least more requests for changes, to the protocol. And so these sorts of issues could legitimately be important to set down. Jason