From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10268 invoked by alias); 1 Oct 2004 14:25:21 -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 10249 invoked from network); 1 Oct 2004 14:25:18 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 1 Oct 2004 14:25:18 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041001142516.GBYW8969.lakermmtao01.cox.net@white> for ; Fri, 1 Oct 2004 10:25:16 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CDOLV-00016f-00 for ; Fri, 01 Oct 2004 10:25:17 -0400 Date: Fri, 01 Oct 2004 14:25:00 -0000 From: Bob Rossi To: GDB Subject: MI and backwards compatibility Message-ID: <20041001142517.GD4100@white> Mail-Followup-To: GDB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00002.txt.bz2 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