From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3977 invoked by alias); 5 Oct 2004 12:11:50 -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 3763 invoked from network); 5 Oct 2004 12:11:40 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 5 Oct 2004 12:11:39 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041005121137.HMRK12437.lakermmtao01.cox.net@white>; Tue, 5 Oct 2004 08:11:37 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CEoAK-0002bj-00; Tue, 05 Oct 2004 08:11:36 -0400 Date: Tue, 05 Oct 2004 12:34:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: g@white, gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041005121136.GA10001@white> Mail-Followup-To: Eli Zaretskii , g@white, 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4aab9$Blat.v2.2.2$c96dbb60@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00077.txt.bz2 On Tue, Oct 05, 2004 at 10:59:37AM +0200, Eli Zaretskii wrote: > > Date: Mon, 4 Oct 2004 09:12:52 -0400 > > From: Bob Rossi > > Cc: gdb@sources.redhat.com > > > > Yes, I understand, that was my first idea. However, you can see that > > it is a "catch 22". If you do not know what version of MI to start GDB > > with, than you can not understand how to parse the output of the MI > > commands. > > 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. 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. > You will need similar machinery for parsing the output of the > command-line switch you suggested. Yes, I understand that adding a new command line switch is not the greatest idea. However, it is the only thing I can think of that allows a front end to ask GDB what versions of MI it supports, without actually needing to know anything about the MI, avoiding the catch 22. Yes I agree that the output of this command line switch could never really change, that seems like a pretty negitive point. > > > To solve that, a front end that is willing to support old versions of > > > GDB will need to have a database of old GDB versions and the MI > > > versions they supported. > > > > I don't see what the GDB versions have to do with, am I missing > > something? I am only interested in the MI versions. > > New MI versions always come with new GDB versions, right? I understand now, I think it would be impossible to figure out what "GDB version" a GDB CVS snapshot is, do you agree? So there would be no way to use a database. Thanks, Bob Rossi