Re: MI rules

[Jim Ingham <jingham at apple dot com>]

On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote:

> On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
> > I have no strong opposition to this, I just don't see the point.
>
> Jim, I appreciate the time you have spent thinking about this issue for
> me. I value the input from someone who has been working with MI for
> quite some time. I have several questions for you,
>
>    1. How do you figure out what type of asynchronous MI output command
>    you just received is?

There are two things here - there is asynchronous output from an MI  
command, like stopped, running, etc.  We added "running breakpoint  
command message so you can tell that it might start up again..."  This  
sort of thing - usually from running.  They are always linked to the  
original command by preserving the command token.  So that's easy.

Then there is true asynchronous communications from the inferior -  
unsolicited messages like shared library notification, or the fact that  
a user command ("interpreter-exec") caused a breakpoint to be set, the  
thread or the frame to be changed, etc...  These are all dealt with  
just as you suggest for commands - they have a tag at the beginning  
specifying the kind of event.  So for instance, when a shared library  
gets loaded, we get:

=shlibs-added,shlib-info= 
[num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld- 
addr="0x83d50000",reason="dyld",requested- 
state="?",state="N",path="",description="/Developer/Applications/ 
Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/ 
PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""]

We are also a bit behind the times, and still use the HOOKS - haven't  
got around to absorbing Andrew's observers yet...  So we also get stuff  
like:

-interpreter-exec console "break captured_main"
Breakpoint 3 at 0x2960: file ../../gdb/src/gdb/main.c, line 122.
^done,MI_HOOK_RESULT={HOOK_TYPE="breakpoint_create",bkpt= 
{number="3",type="breakpoint",disp="keep",enabled="y",addr="0x00002960", 
func="captured_main",file="../../gdb/src/gdb/ 
main.c",line="122",times="0"}}

Again, the truely unsolicited stuff (in this case the breakpoint  
creation notification) is all tagged so the UI can figure out what is  
going on.


>    2. How do you deal with your MI front end dealing with snapshots of
>    GDB? For example, it has new asynchronous commands, but the MI  
> version
>    hasn't been bumped yet.

There are two kinds of additions, right?  Command return fields, and  
async notifications.  In Xcode,
the parser parses everything, and then any command return fields or  
async notifications that it doesn't understand, it ignores.  That's  
pretty much how the MI was designed, so that the MI can freely ADD  
notifications & command return fields, and the UI can just ignore them.  
 The fields are identified by field name, and the notifications by  
their notification name.

If we were to take away a field the UI wanted, then Xcode would  
probably yell at us.  But we don't generally do that, we just add  
stuff.  And of course you can't change the meaning of command arguments  
- that's why Jason has been on the rampage about positional commands in  
the mi - it would be MUCH more robust if they were all of the "command  
-switch value -switch value" type, then they would share the robustness  
of the mi output.

> Finally, I want to make an analogy and I would like for someone to tell
> me where my thinking went wrong.
>
>    GDB and a leaf collecting hobbyist are best friends. For some odd  
> reason,
>    GDB has tons of different kinds of leafs and the hobbyist is just
>    getting his collection started. The hobbyist, named Foo, often asks
>    GDB for a particular kind of leaf, knowing that GDB has it. Since  
> GDB
>    is willing to get rid of some of his collection, he sends to Foo the
>    leaf every time. Sometimes, when GDB finds an extra leaf, he sends  
> it to
>    Foo, even though Foo didn't ask for it. The only problem is, Foo  
> can not
>    figure out what kind of leaf he got, since there are several others
>    that look almost exactly like it. So Foo spends a large portion of
>    the time guessing what kind of leaf he was just given, even though
>    GDB could have just put on the envelope the type of leaf that it
>    was. Foo can not understand why GDB is so mysterious about the leafs
>    he hands out. The end.
>
> hehe, anyways, I'm interested in hearing how you solve the top two
> problems.

We have never really had problems like this.  We send lots of  
notifications that Xcode ignores.  Of course, we might be sending one  
that it really OUGHT to take into account, but if that's true, just  
identifying the notification wouldn't help, it would have to know what  
to do about it.  This sort of reactive logic would be pretty hard to  
run in a data-driven way, so it's probably best to just ignore them,  
get the bug report that something went wrong & Xcode didn't notice it,  
and then go fix Xcode for the next release.

Jim