From: Jim Ingham <jingham@apple.com>
To: Bob Rossi <bob@brasko.net>
Cc: gdb@sources.redhat.com
Subject: Re: MI rules
Date: Mon, 27 Sep 2004 17:39:00 -0000 [thread overview]
Message-ID: <1AB1A5F6-10AC-11D9-8F3A-000A958F4C44@apple.com> (raw)
In-Reply-To: <20040925201242.GA4133@white>
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
next prev parent reply other threads:[~2004-09-27 17:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1095954341.19418.ezmlm@sources.redhat.com>
2004-09-23 18:23 ` Jim Ingham
2004-09-25 1:05 ` Bob Rossi
2004-09-25 19:01 ` Jim Ingham
2004-09-25 20:12 ` Bob Rossi
2004-09-27 17:39 ` Jim Ingham [this message]
2004-09-29 3:00 ` Bob Rossi
2004-09-29 16:13 ` Jim Ingham
2004-09-29 17:27 ` Bob Rossi
2004-09-30 13:26 ` Eli Zaretskii
2004-09-30 16:21 ` Bob Rossi
2004-09-30 16:36 ` Andrew Cagney
2004-09-30 20:42 ` Bob Rossi
[not found] <5733AD9C-0CF7-11D9-8325-000A9569836A@brasko.net>
2004-09-23 0:31 ` Jason Molenda
2004-09-22 13:40 Fabian Cenedese
2004-09-22 13:48 ` Bob Rossi
2004-09-22 14:10 ` Fabian Cenedese
2004-09-22 14:43 ` Bob Rossi
2004-09-22 15:01 ` Fabian Cenedese
2004-09-22 14:58 ` Alain Magloire
2004-09-22 16:18 ` Bob Rossi
2004-09-22 16:59 ` Alain Magloire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1AB1A5F6-10AC-11D9-8F3A-000A958F4C44@apple.com \
--to=jingham@apple.com \
--cc=bob@brasko.net \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).