From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1294 invoked by alias); 4 Oct 2004 15:49:31 -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 1243 invoked from network); 4 Oct 2004 15:49:30 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 4 Oct 2004 15:49:30 -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 <20041004154929.BRPX1698.lakermmtao12.cox.net@white>; Mon, 4 Oct 2004 11:49:29 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CEV5d-0002Cm-00; Mon, 04 Oct 2004 11:49:29 -0400 Date: Mon, 04 Oct 2004 15:58:00 -0000 From: Bob Rossi To: Felix Lee Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041004154928.GE8121@white> Mail-Followup-To: Felix Lee , Eli Zaretskii , gdb@sources.redhat.com References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <20041004145921.BAC77502AB6@stray.canids> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041004145921.BAC77502AB6@stray.canids> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00046.txt.bz2 On Mon, Oct 04, 2004 at 07:59:21AM -0700, Felix Lee wrote: > Bob Rossi : > > OK, at first I don't like this idea for several reasons. It seems to me > > that with this approach you could end up releasing GDB 6.0 with MI > > version 1 and GDB 6.1 with MI version 5. Meaning that there could be > > several versions of MI revisions between one major release. > > It seems that you would have to run the testsuite on every incompatible > > change that the MI protocol goes through, including several for only one > > release. Also, a front end would have to understand all of these > > revisions in hopes of working with the most recent GDB (CVS snapshots). > > I really don't understand what's the problem you're trying to > solve. MI doesn't change often. I'm not interested in how often it changes at all. I'm interested in the fact that it does change. > a front-end > doesn't have to understand any MI changes if it doesn't want to, > if it understands MI5, it should invoke gdb with > --interpreter=mi5. You are correct, a front end doesn't have to do anything if it doesn't want to. However, I want my front end to understand every MI protocol and I think that this is OK with the GDB people. Is it a goal of GDB to make sure that front ends can not understand every protocol? I highly doubt it. > if the gdb doesn't understand mi5, then you can try fallback to > --interpreter=mi1. I don't see much benefit to a front-end > knowing more than two versions of MI, and most of the time > knowing just one should be adequate. Of course there is a benefit. A front end should know every version of the MI protocol. Since it will know all of the protocols, it could work with a given GDB using the latest/greatest protocol that that GDB supported. > if your front-end tries mi5 and fails because gdb has made an > incompatible change to mi5, then that's a bug in gdb, and if that > bug gets exposed in a user version of gdb, the answer is 'your > gdb has a bug, install a non-buggy one'. > > what's your failure scenario? I don't know what you are talking about here. Can you see that I'm interested in having a new front end start any GDB with it's newest MI protocol? Thanks, Bob Rossi