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: Thu, 14 Oct 2004 11:37:20 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> > 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.

I was only talking about stable versions, so developmental is not
something we should consider (we've been through this and decided that
it is unsafe to use such versions).

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

If MI1 is not working and the front end only supports MI1, then this
combination of GDB and front end is not going to work.  So I submit
that this case is not interesting: you will try MI1 and things will go
wrong at some point.

However, ``unsupported'' and ``doesn't work'' are not the same thing.
If we know that a certain version of MI does not work, we should
remove its support from GDB.  If we didn't do that, then we have good
reasons to believe that MI1 does in fact work.

> It would be
> nice if the front end was capable of understanding that.

And then do what? print a message "like unsupported GDB version"?  Is
this really an interesting case?  I thought you were interested in
getting a front end to _work_ with MI; graceful failure is something
different.  Can we please solve one problem at a time?  Do you agree
that if either (1) the front end supports the latest stable version or
(2) the version before that works reasonably well, then printing only
the latest stable version at startup is good enough?

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

I don't see this as a grave problem.

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

Indeed.

> What is wrong with the handshaking protocol that I described?

It is too complicated for the job, IMHO.


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