From: Keith Seitz <keiths@redhat.com>
To: <gdb@sources.redhat.com>
Subject: [MI] Synchronous event notification
Date: Wed, 15 May 2002 11:23:00 -0000 [thread overview]
Message-ID: <Pine.GSO.4.33.0205151055170.5188-100000@makita.cygnus.com> (raw)
Hi,
I've been working on integrating Apple's "-interpreter-exec" changes, and
I wanted to see if I could get some sort of consensus on how event
notifications should be defined.
In the trunk right now, MI ignores event notifications. Adding a mechanism
is vital to the success of MI.
Apple has added this, and all event notifications are tacked onto the
mi-command result:
(gdb)
-interpreter-exec console "break main"
Breakpoint 1 at ...
^done,MI_HOOK_RESULT=[HOOK_TYPE="breakpoint_create",bkpt={number="1",...}]
Right now, this is done by defining a bunch of (existing) hooks when mi
runs. I presume that we want to switch over to using gdb-events, hoping
one day to deprecate the hooks, but that's not really the issue (since
they behave essentially the same in non-asynch). The real question is, how
do maintainers want this information communicated to mi clients?
The example above shows that Apple has added a syntax like:
result ==>
stuff [ "," event-list ]
event-list ==>
"MI_HOOK_RESULT=[" event ( "," event )* "]"
event ==>
"HOOK_TYPE=" event-name [ event-data ]
event-name ==>
"breakpoint_create" | "breakpoint_delete" | ...
and such.
Since hooks are really just event notifications, I would like to propose
that we use a definition like the above, but changing the string literals
a litte:
event-list ==>
"events=[" event ( "," event )* "]"
event ==>
"name=" event-name [ event-data ]
event-name ==>
"breakpoint_create" | "breakpoint_delete" | ...
Please discuss.
Keith
next reply other threads:[~2002-05-15 18:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-15 11:23 Keith Seitz [this message]
2002-05-24 13:41 ` Andrew Cagney
2002-05-24 15:26 ` Keith Seitz
2002-06-01 15:25 ` Andrew Cagney
2002-05-24 14:52 thomson
2002-05-24 15:31 ` Keith Seitz
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=Pine.GSO.4.33.0205151055170.5188-100000@makita.cygnus.com \
--to=keiths@redhat.com \
--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