From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6611 invoked by alias); 25 Aug 2004 13:23:23 -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 6587 invoked from network); 25 Aug 2004 13:23:22 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 25 Aug 2004 13:23:22 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id IAA27415 for ; Wed, 25 Aug 2004 08:37:47 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id JAA11515 for gdb@sources.redhat.com; Wed, 25 Aug 2004 09:23:21 -0400 Message-Id: <200408251323.JAA11515@smtp.ott.qnx.com> Subject: Re: MI level command To: cagney@gnu.org (Andrew Cagney) Date: Wed, 25 Aug 2004 13:23:00 -0000 From: "Alain Magloire" Cc: alain@qnx.com (Alain Magloire), gdb@sources.redhat.com In-Reply-To: <412BBB2D.7040108@gnu.org> from "Andrew Cagney" at Aug 24, 2004 06:03:25 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00366.txt.bz2 > > > 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. > Yes, some embedded platforms are still using old versions and for whatever reasons and can not move the latest/greatest. Frontends still need to cope with this and detecting the version of MI will allow them to adjust. > 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 > 100% agreement, here 8-). Thanks.