From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10665 invoked by alias); 6 Oct 2004 11:39:19 -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 10628 invoked from network); 6 Oct 2004 11:39:17 -0000 Received: from unknown (HELO lakermmtao05.cox.net) (68.230.240.34) by sourceware.org with SMTP; 6 Oct 2004 11:39:17 -0000 Received: from white ([68.9.64.121]) by lakermmtao05.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006113916.RKLP20854.lakermmtao05.cox.net@white>; Wed, 6 Oct 2004 07:39:16 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFA8a-000352-00; Wed, 06 Oct 2004 07:39:16 -0400 Date: Wed, 06 Oct 2004 11:47:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006113916.GC11747@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20041003170104.GC7030@white> <01c4a9cf$Blat.v2.2.2$5a064020@zahav.net.il> <20041004131252.GA8121@white> <01c4aab9$Blat.v2.2.2$c96dbb60@zahav.net.il> <20041005121136.GA10001@white> <01c4ab8b$Blat.v2.2.2$19b96200@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4ab8b$Blat.v2.2.2$19b96200@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00119.txt.bz2 On Wed, Oct 06, 2004 at 11:57:56AM +0200, Eli Zaretskii wrote: > > Date: Tue, 5 Oct 2004 08:11:36 -0400 > > From: Bob Rossi > > Cc: g@white, gdb@sources.redhat.com > > [Could you please remove that "g@white" from the CC list? It bounces, > so I need to manually remove it, which is a pain, as I respond to too > many mails daily to afford editing the headers. If you need that for > your purposes, please use Bcc.] Yes, I'm sorry about that. > > > I don't see any catch: the output of this specific command could be > > > made very simple so that it will not need any parsing, just some > > > trivial string matching or at most regexps. > > > > IMHO, it doesn't matter how easy it is to parse the MI output, it should > > be done algorithmically. Simple or complicated, the same MI output > > parser that parses the entire MI output syntax should be capable of > > parsing the command we are suggesting. > > That's a given. What I meant to say was that the output of this > command could be so simple (e.g., a simple string with no structure) > that every MI parser would understand that. Thus no catch-22. 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? For instance, if in MI3, the MI output syntax was changed to add a label for each MI output command to tell the front end what type of command is being transmitted, or if any incompatible change was added to the output syntax, than the parser for MI2 and MI3 would not work with each other. In this case alone, the front end can not start up GDB with a specific version of MI. It needs to get from GDB the versions of MI that it supports, and then start it up in the highest compatible mode. This is why there needs to be a non-MI command to figure out what MI versions the current GDB supports. It is also why I am claiming that there is a catch-22. > > The goal is to find out what versions of MI GDB supports so that you can > > start GDB up in the highest compatible mode. Right? > > > > How can you start GDB up in MI mode to ask it for the MI versions it > > supports? You don't know what MI modes it supports, so you can not start > > it in MI mode. That's the catch 22. > > Again, I see no catch. Here's what I had in mind: > > foo$ gdb -interpreter=mi > [the starting blurb omitted] > (gdb) -mi-version > mi3 > > After this, the front end could either (1) quit GDB and restart it > with a "-interpreter=mi2" (say) switch, or (2) modify its parsing to > adapt to MI version 3. If I am proven to be wrong above, then this would be fine with me. Bob Rossi