Re: MI rules

[Jim Ingham <jingham@apple.com>]

I have no strong opposition to this, I just don't see the point.

I think any sane implementation of the MI driver is going to want to 
use the command tokens to keep track of the commands that are issued, 
to make sure something hasn't been dropped on the floor, do good error 
reporting - "Which command was it that went wrong..." etc.  And once 
you are doing that, you always know exactly what command you issued and 
what you got back.

OTOH, adding some kind of command identifier to the return is mostly 
pretty easy, you can just hook into the mechanism that issues the 
command token.  Note that this code is not quite as trivial as it seems 
- and I think the FSF version doesn't work correctly in all cases - 
particularly with async targets, and when you allow things like 
breakpoint commands.

For instance if you allow breakpoint commands that can cause the target 
to run (like a "continue" in a breakpoint command) for an asynchronous 
target, you will get a stopped message, but then you have to issue 
another ^running and maybe some indication of what happened to the GUI, 
and all these are bound to the original -exec-continue or whatever got 
the target going.

I fixed a bunch of this stuff on our side, and I don't remember seeing 
similar work go on on the FSF side (though I may have missed it).  
Sadly that sits on top of a pile of other changes to support 
asynchronous targets that only exist on our side...  But you should at 
least be aware that this is not entirely straight-forward...

OTOH, if you ever get to your goal of having a data-driven validator 
for the command returns, I can see it might be useful.

A few specific comments below...


On Sep 24, 2004, at 6:05 PM, Bob Rossi wrote:

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

This has just never come up in the 4 years I have been supporting the 
Xcode guys.  There are LOTS of things they want from us, some of which 
we have provided, some not.  But this one has never seemed a problem.

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

This IS what the command tokens are for.  I don't at all think it is a 
good idea to replicate this mechanism.  As it stands it works just 
fine, and I don't see any point in doing it twice, that just introduces 
more chances for bugs.  And you certainly want a general mechanism to 
tag every command you issue, so you can't replace it with a command 
specific mechanism.

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

Not unreasonable, just more code that we have to maintain for what 
seems to me like marginal benefit.

Tracking the tokens and getting them to be right is not quite as 
trivial as it seems, and this just adds a little more weight to that 
mechanism.  But given that that already works, if you can hook onto 
that you can probably do it without adding to much of a maintenance 
burden.

It will probably also be an incompatible change, so you will have to 
mark it as such.

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

Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb