This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[MI] Synchronous event notification
- From: Keith Seitz <keiths at redhat dot com>
- To: <gdb at sources dot redhat dot com>
- Date: Wed, 15 May 2002 11:23:01 -0700 (PDT)
- Subject: [MI] Synchronous event notification
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