From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20405 invoked by alias); 7 May 2003 20:28:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20386 invoked from network); 7 May 2003 20:28:44 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 7 May 2003 20:28:44 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id QAA15627 for ; Wed, 7 May 2003 16:25:55 -0400 Received: from node1.ott.qnx.com (hwlab1 [10.0.2.159]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id QAA06785 for ; Wed, 7 May 2003 16:28:43 -0400 Received: (from alain@localhost) by node1.ott.qnx.com (8.8.8/8.6.12) id QAA03258 for gdb-patches@sources.redhat.com; Wed, 7 May 2003 16:28:41 -0400 Message-Id: <200305072028.QAA03258@node1.ott.qnx.com> Subject: Re: [RFC] -mi-level command To: gdb-patches@sources.redhat.com Date: Wed, 07 May 2003 20:28:00 -0000 From: "Alain Magloire" In-Reply-To: <3EB95ACB.2050807@redhat.com> from "Andrew Cagney" at May 07, 2003 03:13:15 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00097.txt.bz2 > > > > Bonjour > > > > Maybe there is a better way to do this, most clients of GDB/MI > > need a way to know the level to adjust the parsing or go around bugs in > > previous(or current version). > > > > One problem with the code below is that mi_version() is returning ..."3" > > Should it also include the gdb version string? It is already covered by: -gdb-version > Should it indicate the range of supported MI versions? > (what ever is useful). I think what you are referring is a set command like -mi-set-level "mi2" In this case, I am only interested in knowing the mi protocol version. For example the parsing of "-thread-list-ids" at level "mi1" is completely different then "mi2" and "mi3". "mi0" != "mi1" != "mi2" != "mi3" In otherwords having "mi2" does not mean I can parse output or use command of "mi1" level. It is probably not possible to be backward compatible. Backward compatible would imply a parser that was written for "mi0" should work for "mi1" or "mi2" ... It is currently not the case. It is important for the folks using "GDB/MI" to know the version when exchanging with gdb because of this, spawning "gdb -i mi" does not say much. > > 'gdb -i=mi2' should get you back to something that was released in 5.3. > "mi3" won't become official until GDB 6 is released, however, for it > it return "2" would be wrong. > Well the problem is that the function mi_version() is returning "3" How can I, reliably, get the MI version beeing use? > It will need documentation and a testcase. > Agreed, will do, if the new command is accepted. BTW: seems to have some confusion with "MI level" and "MI version" Should the command name be : -mi-level or -mi-version ?? > Andrew > > There is a problem here though 8-) ok.