Re: MI rules

Jim Ingham
2004-09-27T17:39:02Z

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