Re: MI rules

[Jim Ingham <jingham@apple.com>]

Sorry for being so late in chiming in, but I guess I am not clear on 
exactly what the problem is here.

Xcode uses the command tokens through-out, so it always is able to 
match up the command & it's result.  We had to do some work to make 
sure that if a command like -exec-run gets the target going, and you 
come along and issue another command, you still get a running & a 
stopped that have the correct numbers.

But I don't think this would be a real problem for the FSF gdb right 
now, since there are very few real (any)asynchronous targets in actual 
use. If there are, you can look at what we had to change to get this 
working.  It was tricky IIRC, but not that bad.

Anyway, you almost always will need more information than just "what 
was the name of the MI command that I issued", right?  You can issue a 
whole bunch of "-var-create" commands, for instance, and just knowing 
that you issued -var-create isn't going to help you at all.  You need 
to tie each one to the particular variable the varobj was representing. 
  So issuing & keeping track of the tokens is pretty much mandatory 
anyway, and once you are doing that, you pretty much know how to 
interpreter each return value.

Other that that, there are the asynchronous notifications that come 
from gdb when something interesting happens, but those should already 
all have some unique tag after the "=" that tells you what the data is.

I don't have any big problem with adding the command name after the 
command token or something similar, but I don't see that it really adds 
much in practical terms.  It also looks to me like this will be a 
backwards-incompatible change to the mi, no?  If so you should bump the 
MI version if you add this.

Jim



On Sep 23, 2004, at 8:45 AM, gdb-digest-help@sources.redhat.com wrote:

>
>
> On Wed, Sep 22, 2004 at 12:18:06PM -0400, Bob Rossi wrote:
>
>> I wasn't being critical at all. Personally, I don't like the fact that
>> Eclipse use's a hybrid approach to getting data out of GDB. I have not
>> even started adding MI to CGDB because I've been working on GDB,
>> bringing it up to the standards I need to get CGDB fully usable by 
>> only
>> using MI. If others would follow this approach, I'm sure my life would
>> have been a lot easier, and CGDB would have been far more along.
>
> For what it's worth, Xcode (the IDE on MacOS X) uses something like
> one non-MI command these days ("tty").  It's true that we've done a
> lot of work on the MI side of gdb, but an example of an MI-only
> (well, nearly so - there's no bonus points for having 100% MI usage
> so we have that one command there) exists and has been shipping for
> at least a few years now.  NB Xcode is gratis free, but not libre free,
> i.e. not free software.
>
> J