From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13915 invoked by alias); 6 Oct 2004 10:01:26 -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 13898 invoked from network); 6 Oct 2004 10:01:23 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 6 Oct 2004 10:01:23 -0000 Received: from zaretski ([80.230.143.237]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CTL24366 (AUTH halo1); Wed, 6 Oct 2004 12:01:07 +0200 (IST) Date: Wed, 06 Oct 2004 10:19:00 -0000 From: "Eli Zaretskii" To: Bob Rossi Message-ID: <01c4ab8b$Blat.v2.2.2$19b96200@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com In-reply-to: <20041005121136.GA10001@white> (message from Bob Rossi on Tue, 5 Oct 2004 08:11:36 -0400) Subject: Re: probing GDB for MI versions Reply-to: Eli Zaretskii 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> X-SW-Source: 2004-10/txt/msg00115.txt.bz2 > 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.] > > 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. > 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. In other words, I don't need to know what MI versions GDB supports to start it in MI mode. > > 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. Someone else already replied to this: the development snapshots do have a unique version string, which does allow for a database, although making the database work for snapshots would require some support code (because you don't want to have an entry for each day between official releases).