This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [MI] Synchronous event notification
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 24 May 2002 16:41:46 -0400
- Subject: Re: [MI] Synchronous event notification
- References: <Pine.GSO.4.33.0205151055170.5188-100000@makita.cygnus.com>
(I had to go and read over some old notes).
> 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",...}]
Looking at the old notes, I think the intent was:
(gdb)
-interpreter-exec console "break main"
&"Breakpoint 1 at ..."
*breakpoint-create,pkpt={number="1',...}
^done
The actual example I found was:
> Command with side effects:
> -> -symbol-file xyz.exe
> <- *breakpoint nr=3 address=0x123 source=a.c:123
> <- (gdb)
It is a really old example and you can see how the syntax evolved :-)
> 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).
Yes, they are essentially the same. The gdb-events just tries to
collect everything together. The idea being that, for instance, several
things could ``observe'' GDB. However, it might just be over-engineering.
> 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" | ...
So:
^done,result=...,events=...
So that, for a ``synchronous'' command the events just get bundled with
the result. Sounds ok, definitly has a certain elegance - here is the
result, here are all the sideeffects.
One question, what about a more asynchronous operation? A running
target starts loading shared libraries, inserting breakpoints, running
scripts, et.al. There the synchronous nature is gone. I guess:
- notify of all the events when the target next ``stops''
- notify the events on-the-fly (possibly incuring an overhead?)
Andrew
> Please discuss.
> Keith