From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24684 invoked by alias); 24 Aug 2004 23:54:53 -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 24674 invoked from network); 24 Aug 2004 23:54:51 -0000 Received: from unknown (HELO lakermmtao03.cox.net) (68.230.240.36) by sourceware.org with SMTP; 24 Aug 2004 23:54:51 -0000 Received: from white ([68.9.64.121]) by lakermmtao03.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040824235448.NKWD12737.lakermmtao03.cox.net@white>; Tue, 24 Aug 2004 19:54:48 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Bzl7n-0004oY-00; Tue, 24 Aug 2004 19:54:47 -0400 Date: Tue, 24 Aug 2004 23:54:00 -0000 From: Bob Rossi To: Andrew Cagney Cc: Alain Magloire , gdb@sources.redhat.com Subject: Re: MI level command Message-ID: <20040824235447.GA18340@white> Mail-Followup-To: Andrew Cagney , Alain Magloire , gdb@sources.redhat.com References: <200407082333.TAA25718@smtp.ott.qnx.com> <412BBB2D.7040108@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412BBB2D.7040108@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-08/txt/msg00356.txt.bz2 On Tue, Aug 24, 2004 at 06:03:25PM -0400, Andrew Cagney wrote: > >Yellow > > > > > >Scenario: We want to know wich level of MI that we are currently working > >in. > > This can allow to adjust what MI command to use and how to parse them. > > > >Problems: No such command in MI and no GDB variable that we can test via > >-gdb-show. > > The version of gdb > > gdb --version > > show different things in different distributions, sometimes it is a > > number based on date > > etc ... > > > >So would a patch implementing > > > > -gdb-mi-level > > ^done,level=1 > > > >be a good thing ? > > This needs to be resolved. > > I think its become clear that clients are choosing to support multiple > debugger releases rather than certifying against a single debugger and > mi version. This is contrary to the expectation that the clients would > tightly couple their front end to a specific GDB and MI version, and > consequently, when starting GDB, specify a specific MI version. > > Given this, we need to change the way versioning is handled. > > - we can't create a situtation where GDB is required to retain existing > [broken] behavior indefinitly > > - we can certainly look for ways that let the client use both old and > newer GDB's - the clients then get to decide how much backward > incompatibility they wish to retain without imposing the burdon on GDB. > > To that end: > > -> we should probably implement significant command output (and more > importantly input) changes by adding a new command. A missing new > command is easy to detect, just run it with no options. > > -> minor output changes (new field for instance) do not need a new command > > -> MI version changes tied to significant changes Agreed, this would be a *great* step in the right direction. I propose that for every mi command, we give the signature, so that the client knows exactly what the command is capable of. Just saying that a command is there is not good enough. It's very similar to POSIX coming out with a standard that says, the function named select and poll must be present and then a C programmer trying to interface with that function. Thanks, Bob Rossi