From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28075 invoked by alias); 5 Oct 2004 13:30:23 -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 27849 invoked from network); 5 Oct 2004 13:30:14 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 5 Oct 2004 13:30:14 -0000 Received: from white ([68.9.64.121]) by lakermmtao12.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041005133013.JORR3420.lakermmtao12.cox.net@white>; Tue, 5 Oct 2004 09:30:13 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CEpOP-0002e9-00; Tue, 05 Oct 2004 09:30:13 -0400 Date: Tue, 05 Oct 2004 13:37:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: Fabian Cenedese , gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041005133013.GA10125@white> Mail-Followup-To: Eli Zaretskii , Fabian Cenedese , gdb@sources.redhat.com References: <20041004131906.GB8121@white> <20041004145921.BAC77502AB6@stray.canids> <20041004154928.GE8121@white> <20041004160455.DD23A502AB6@stray.canids> <20041004164803.GG8121@white> <20041004181201.9A8E9502AB6@stray.canids> <20041004183145.GH8121@white> <20041004205357.1FBCD502AB6@stray.canids> <5.2.0.9.1.20041005085052.01ce8e18@NT_SERVER> <01c4aaba$Blat.v2.2.2$d1019f80@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4aaba$Blat.v2.2.2$d1019f80@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00083.txt.bz2 On Tue, Oct 05, 2004 at 11:06:59AM +0200, Eli Zaretskii wrote: > > Date: Tue, 05 Oct 2004 08:59:32 +0200 > > From: Fabian Cenedese > > > > One thing that could be added is that -i mi doesn't mean the last > > one (like mi2 now) but the last official one. So if there will be a > > mi3 in progress mi will still select mi2. Like that you will always > > be using the last stable protocol. And others can work with the > > development version by calling -i mi3. But that won't solve your > > problem of knowing what mi version the last stable really is. > > Knowing which MI version is the last stable one is important, but it's > a separate issue. Do we all agree that for official GDB releases the > problem of MI versions is solved by the features that we already have, > or do someone think that a feature that reports supported MI versions > is still needed even for the official releases? Let's solve the > situation with official releases first, and get to the development > versions later. I didn't think there was a problem with using a GDB stable version MI protocol. This I expected to work the way the documentation described. I started this thread to figure out how to deal with development versions which were a side effect of using CVS snapshot's of GDB. However, I still think that it is necessary to know the supported MI versions, if the GDB is a stable or a development version. I started the thread, "probing GDB for MI versions" http://sources.redhat.com/ml/gdb/2004-10/msg00027.html to resolve this issue (you obviously already know about this, but other people might not) It is a requirement of the front end to figure out the highest common MI protocol that both it and GDB speek. This needs to be done before any communication can occur between GDB and the front end. > As for the problem with development versions, I think it's part of a > larger problem: how can one know that a certain snapshot is stable > enough to make it available to users? I do not know how to answer this question, and I assume that using a CVS snapshot means that the MI protocol is under development and that it should not be used. > The stability of MI is a > relatively small aspect of this larger problem, and there's always the > solution suggested by Jason (I think): use the latest stable version > of MI, the one released with the last official GDB version. This seems like a good idea to me. I think that we have come to the conclusion that the cutting edg MI protocol that comes with a CVS snapshots of GDB should not be used. It is essential that the front end can figure out the last stable version of MI that was supported. Bob Rossi