Re: MI rules

[Bob Rossi <bob at brasko dot net>]

On Thu, Sep 23, 2004 at 11:23:18AM -0700, Jim Ingham wrote:
> Sorry for being so late in chiming in, but I guess I am not clear on 
> exactly what the problem is here.

Don't be, thanks for responding.

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

OK, I understand that it is possible to use the tokens to be able to
tell what MI output commands is coming out of GDB when it is issuing
syncronous commands.

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

This is a good point. I haven't got this far in my implementation.

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

Please take a look at 
http://sources.redhat.com/ml/gdb/2004-09/msg00200.html

I have summarized the two issues better there. One of the issues is more
important, and that deals with MI outuput commands and backwards
compatibility.

Finally, I personally think that every MI output command should self
document what type of command it is. This tells the front end easily
what kind of MI output command walker should be used to understand the
data. I understand the front end could use the tokens to figure it out,
but I think it's something that should be self evident from having the
MI output command. 

Finally, for instances like -var-create I would suggest adding a new
field to the -var-create that gives it a unique id ( like tokens ).
Then, whenever a -var- response from GDB it should tell you that it is
issuing a -var-create response and it is tied to the unique id. That way
the front end can match it up.

Personally, I think all of these things can be done easily at the GDB
level and can avoid unnecessary confusion in the front ends.

Does it sound unreasonable for a MI output command, either syncronous or
asyncronous to say what kind of command it is?

Input is greatly appreciated since I've already made it passed the
parsing stage of the MI output commands and want to start interpretting
the data. Basically, I hope that the bison parser that I have will be
usable by other front end developers one day. I also think that for each
MI output command that they get, they should be able to understand how
to interpret the data, without having to do lookups to figure out what
type of command it is, or wihtout having to look at the data to figure
out what kind of command it is.

Thanks,
Bob Rossi