This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]