This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: probing GDB for MI versions
> Date: Tue, 5 Oct 2004 08:11:36 -0400
> From: Bob Rossi <bob@brasko.net>
> 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).