Re: probing GDB for MI versions

'Bob Rossi'
2004-10-14T15:37:27Z

On Wed, Oct 13, 2004 at 10:29:31PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 13 Oct 2004 08:14:12 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> >
> > > What's wrong with a simpler idea already suggested here: that GDB will
> > > output the MI version as part of the starting blurb when invoked with
> > > "-interpreter=mi" option?
> >
> > That method is fine if GDB supports only one stable MI protocol at a
> > time. However, I have been told that GDB will support multiple versions
> > of MI at a time.
>
> Yes, but Andrew just told you that GDB will most probably support at
> most 2 MI versions: the latest one and the one before that. So
> printing only the last version is okay, because if that version is not
> supported by your front end, you need only to check the previous
> version. Isn't that good enough?
>
> (Even if GDB does support more than 2 MI versions, you could still
> probe smaller versions until you either (1) find one that is okay with
> your front end, or (2) get GDB to fail because the MI version you
> requested is not supported.

I can give several reasons why this is not good enough. As far as I can
tell, there are 3 types of MI protocols. Supported, unsupported and
developmental. This information needs to be given to the front end. For
example, right now GDB supports MI2. However, if a front end understood
only MI1, then it would be tempted to try MI1 with your approach.
However, MI1 is unsupported and most likely doesn't work. It would be
nice if the front end was capable of understanding that.

> And if that is still not good enough, let's have GDB output a list of
> supported MI versions as part of its starting blurb, e.g. one version
> per line.

This seems reasonable. There are 2 down sides that I don't like

* There is no handshaking being done. Average case scenario is starting
GDB twice to get it into the correct mode. Once to find out the
supported versions, second to start it in the correct mode.

* It tells the front end only the minimum information it needs to
know. (developmental and unsupported interfaces are not printed)
Again, this probably isn't to important.

If we implement the handshaking solution that I had, it is guaranteed that
the front end will be able to start GDB only once and get it into the
correct MI protocol.

What is wrong with the handshaking protocol that I described? I see it
as the optimal solution and would be happy to implement it.

> Will that finally put this issue to rest?

I understand this issue is long and drawn out, however, it is critical
for a front end to GDB that plans on working with multiple GDB's and
not just one that is bundled together.

Thanks for helping out!

Thanks,
Bob Rossi