From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7427 invoked by alias); 24 Aug 2004 22:04:37 -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 7414 invoked from network); 24 Aug 2004 22:04:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Aug 2004 22:04:37 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7OM4aS2029312 for ; Tue, 24 Aug 2004 18:04:36 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7OM4Za30602; Tue, 24 Aug 2004 18:04:35 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ED3812B9D; Tue, 24 Aug 2004 18:03:25 -0400 (EDT) Message-ID: <412BBB2D.7040108@gnu.org> Date: Tue, 24 Aug 2004 22:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Alain Magloire Cc: gdb@sources.redhat.com Subject: Re: MI level command References: <200407082333.TAA25718@smtp.ott.qnx.com> In-Reply-To: <200407082333.TAA25718@smtp.ott.qnx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00353.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. 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 Andrew