From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2399 invoked by alias); 6 Oct 2004 17:04:01 -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 2352 invoked from network); 6 Oct 2004 17:03:59 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 6 Oct 2004 17:03:59 -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 MAA15249 for ; Wed, 6 Oct 2004 12:59:03 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id NAA29043 for gdb@sources.redhat.com; Wed, 6 Oct 2004 13:03:59 -0400 Message-Id: <200410061703.NAA29043@smtp.ott.qnx.com> Subject: Re: probing GDB for MI versions To: bob@brasko.net ('Bob Rossi') Date: Wed, 06 Oct 2004 17:05:00 -0000 From: "Alain Magloire" Cc: dk@artimi.com (Dave Korn), eliz@gnu.org ('Eli Zaretskii'), gdb@sources.redhat.com In-Reply-To: <20041006162225.GA12213@white> from "'Bob Rossi'" at Oct 06, 2004 12:22:25 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00144.txt.bz2 > > On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote: > > > -----Original Message----- > > > From: gdb-owner On Behalf Of Bob Rossi > > > Sent: 06 October 2004 12:39 > > > > > Unfortunately this topic is on two different threads. I feel > > > badly that I > > > am wasting your time here with bad descriptions of the > > > "catch-22". This > > > is to help make my opinion clear on why it is a "catch-22" and not > > > possible. > > > > > > The front end has parsers for different versions of GDB's > > > MI protocol. > > > The parser for MI2 may not work for the MI3 protocol. > > > The parser for the MI3 protocol may not work for the MI2 protocol. > > > The front end *can not* start up GDB just by using -interpreter=mi > > > because it doesn't know what parser to use in this situation. > > > Can we agree on this point for starters? > > > > No, we can't. As long as the output from the -mi-version MI command stays > > in the same format, you can always parse that and determine which version to > > use. > > Dave, you do not understand the problem at all. I do not appreciate your > defininative answer, especially since it is incorrect. > > The actual MI output syntax is capable of changing between MI versions. > If the MI4 output syntax (grammar) has an incompatible change with MI3, > then > * the MI3 parser will not even be capable of parsing and building a > parse tree for the MI4 protocol. > * the MI4 parser will not even be capable of parsing and building a > parse tree for the MI3 protocol. > > It is not possible to understand the output of the command no matter how > simple it is. If there is no parse tree, then there is no way to > understand the output from GDB. > > > Everything else can change. You can start up with an utterly minimal, > > unintelligent parser, that knows nothing except how to send a -mi-version > > command and parse the output; that parser can then direct one of your > > version-dependent parsers to take over. > > I don't understand the concept of an "utterly minimal unintelligent parser". > That is rediculous. I am generating a parser from the grammar. > > There absolutly needs to be a way for the front end to ask GDB what > versions of the MI protocol it supports. > > There is no way the front end can ask GDB what protocols it supports if > it needs to talk to it with an MI protocol. Understood? > I'm not sure on your rationnale to reject Dave's proposition. It seems to me it is a perfectly valid alternative for a front-end to probe gdb and do an educated guess on what the better version of MI it can support. gdb --interpreter=mi executable (gdb) 1-mi-level 1^done,value="1" The front-end loads MI Parser level 1 and continue exchange with gdb. The other approach that was suggested, seems also interresting; asking gdb on the command line for the list of protocols. This first pass probing will allow the front-end to make a good choice also. The first idea to keep on probing gdb : $ gdb -i mi5 executable Interpreter `mi45' unrecognized # try a nother $ gdb -i mi4 executable Interpreter `mi4' unrecognized $ gdb -i mi2 executable Bingo !!! seems cumbersone but should work. The problem that I did not see you mention in any previous thread, is when there is a bug fix !! for example: -thread-list-ids, keep on crashing, the next version of gdb fixes the problem, how will a front-end knows to not use "info threads" but can now use "-thread-list-ids". Andrew's answer to this was to look at the gdb version and make an educated guess, but we know the problem with this, many distrubution have mangle gdb --version (Just came back from a 2 weeks break, so I may have missed some context).