From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4112 invoked by alias); 6 Oct 2004 17:05:15 -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 4102 invoked from network); 6 Oct 2004 17:05:14 -0000 Received: from unknown (HELO lakermmtao03.cox.net) (68.230.240.36) by sourceware.org with SMTP; 6 Oct 2004 17:05:14 -0000 Received: from white ([68.9.64.121]) by lakermmtao03.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006170513.EHNZ13098.lakermmtao03.cox.net@white>; Wed, 6 Oct 2004 13:05:13 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFFE1-0003FX-00; Wed, 06 Oct 2004 13:05:13 -0400 Date: Wed, 06 Oct 2004 17:12:00 -0000 From: 'Bob Rossi' To: Dave Korn Cc: 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006170513.GG12213@white> Mail-Followup-To: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com References: <20041006162225.GA12213@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00145.txt.bz2 Sorry if I was rude here, I am very frustrated. No one has attempted to do what I am trying to do. Write a front end that is capable of working with different GDB's. If they do do this, I would like to know how they negotiate the MI version to talk. Again, you seem to be saying that if I generate a parser off of the MI output syntax, that I am somehow wrong. Is this the general feel of the community? Bob Rossi On Wed, Oct 06, 2004 at 05:55:28PM +0100, Dave Korn wrote: > > -----Original Message----- > > From: 'Bob Rossi' > > Sent: 06 October 2004 17:22 > > > 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 > > > > > 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. > > #1. Well, I don't appreciate your rudeness, but hey, we don't always get > what we want in life. Guess you're just SOL. > > #2. My answer IS correct. I DO understand the problem, and in fact I > understand it better enough than you do that I can see the very very obvious > solution (that you aren't capable of grasping) as well as the problem > itself. > > #3. Why do you have to be the _only_ person in the entire software industry > who isn't capable of dealing with elementary versioning and compatibility > issues? These techniques work fine for EVERYONE else but you. > > > The actual MI output syntax is capable of changing between MI > > versions. > > Yes. I hope we're all agreed that there is no hope of (nor point to) > tracking a work-in-progress as it changes on a day-by-day basis. > > > 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. > > Try and think outside the box. Your over-reliance on tools is hobbling > you. You aren't obliged by statute to use an automatically generated parser > based on a formal grammar. You can use printf to send the -mi-version > command to the gdb instance, and you can use sscanf to parse the version > number out of the string "MI version is XXXX" that it returns. > > > It is not possible to understand the output of the command no > > matter how simple it is. > > Speak for yourself. I can understand it, it's human readable. I could > write a very very very simple bit of code using sscanf that would understand > it. You might have a problem understanding it, but you're the only one who > does, and there's no need for you to. > > >If there is no parse tree, then there is no way to > > understand the output from GDB. > > Don't be so facile. You send one very simple command, get back one very > simple output that you can parse with strcmp or sscanf, for crying out loud. > Then you know what MI version you're dealing with. > > > I don't understand the concept of an "utterly minimal > > unintelligent parser". > > Well, you're clearly biting off more than you can chew with this entire > project. As I said above, something of the degree of complexity of a single > sscanf statement is what I mean. > > > 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 understand what you're claiming, but I gave you a perfectly clear and > simple way of doing it. You haven't demonstrated any problem with my > proposal, because as you said above, you haven't even understood it yet. > When you do understand it, you'll also understand that it works just fine. > > cheers, > DaveK > -- > Can't think of a witty .sigline today....