From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2252 invoked by alias); 4 Oct 2004 14:59:26 -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 2243 invoked from network); 4 Oct 2004 14:59:25 -0000 Received: from unknown (HELO epic.mail.pas.earthlink.net) (207.217.120.181) by sourceware.org with SMTP; 4 Oct 2004 14:59:25 -0000 Received: from ip216-26-76-19.dsl.du.teleport.com ([216.26.76.19] helo=stray.canids) by epic.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CEUJ9-0000Di-00; Mon, 04 Oct 2004 07:59:23 -0700 Received: from stray.canids (localhost.localdomain [127.0.0.1]) by stray.canids (Postfix) with ESMTP id BAC77502AB6; Mon, 4 Oct 2004 07:59:21 -0700 (PDT) From: Felix Lee To: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> In-Reply-To: <20041004131906.GB8121@white> on Mon, 04 Oct 2004 09:19:06 EDT from Bob Rossi Date: Mon, 04 Oct 2004 15:34:00 -0000 Message-Id: <20041004145921.BAC77502AB6@stray.canids> X-SW-Source: 2004-10/txt/msg00044.txt.bz2 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. and even if it did, each version of MI has separate tests in the testsuite. 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. 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. 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? --