From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28301 invoked by alias); 2 Oct 2004 15:38:18 -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 28147 invoked from network); 2 Oct 2004 15:38:16 -0000 Received: from unknown (HELO lakermmtao11.cox.net) (68.230.240.28) by sourceware.org with SMTP; 2 Oct 2004 15:38:16 -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 <20041002153816.WFWI24786.lakermmtao11.cox.net@white> for ; Sat, 2 Oct 2004 11:38:16 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CDlxf-0001Vv-00 for ; Sat, 02 Oct 2004 11:38:15 -0400 Date: Sat, 02 Oct 2004 16:26:00 -0000 From: Bob Rossi To: GDB Subject: Re: MI and backwards compatibility Message-ID: <20041002153815.GC5224@white> Mail-Followup-To: GDB References: <20041001142517.GD4100@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041001142517.GD4100@white> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00018.txt.bz2 Ping. I guess the main questions is, is the goal of GDB to support old versions of MI? For instance, if GDB is currently at MI3, will it support a front end that only knows MI2? If so, then I need the documentation for the MI2 interface if I want to make my front end work with that version of the protocol. This is a general issue and quit frankly a very simple question. Could I get a response to at least what GDB does now. Then, maybe we can talk about what it should do, and if it is doing what it should do. Thanks, Bob Rossi On Fri, Oct 01, 2004 at 10:25:17AM -0400, Bob Rossi wrote: > Hi, > > Taking Eli's suggestion, I am starting a simple discussion here only on > how front end developers should expect there front end to work with > different versions of GDB. > > >From Eli Zaretskii > > All the MI versions except the latest are kept for one reason only: > > backward compatibility. So an already existing front end should use > > the version it was written to support, while a new front end should > > use the latest version, the one invoked by "-interpreter=mi". Doesn't > > this solve the problem? If not, why not, and what solutions you can > > suggest to solve that? > > I guess the *real* problem is how we expect a front end and multiple > versions of GDB work together. I think there needs to be a section in the > documentation that describes backwards compatibility. For instance, I > think that a front end programmed to understand mi1 should always work > with a GDB that is capable of outputting mi1. For instance, here are > some example GDB's and MI versions for demonstration, > > GDB version with MI versions > > GDB 1.0 -> mi1 > GDB 2.0 -> mi1,mi2 > GDB 3.0 -> mi1,mi2 > GDB 4.0 -> mi1,mi2,mi3 > GDB 5.0 -> mi1,mi2,mi3,mi4 > > Front end version which understands MI version > FE 1.0 -> mi2 > FE 2.0 -> mi2,mi3 > FE 3.0 -> mi2,mi3,mi4 > > So, here is an example that I don't see to far fetched within the next > few years. The question is, what does backwards compatibility mean? > This is what I expect, > > FE 1.0 or after to never work with GDB 1.0 > FE 1.0 to work with GDB 2.0 on using mi2. > FE 2.0 to work with GDB 2.0 and 3.0 using mi2 > and with GDB 4.0 on with mi3 > FE 3.0 to work with GDB 2.0 and 3.0 using mi2 > and with GDB 4.0 with mi3 > and with GDB 5.0 with mi4 > > Is this what everyone else expects? > > Thanks, > Bob Rossi