Re: [MI] Synchronous event notification

[thomson@ca.ibm.com]

Keith Seitz wrote:

>The example above shows that Apple has added a syntax like:
>
>  result ==>
>     stuff [ "," event-list ]
>  event-list ==>
>     "MI_HOOK_RESULT=[" event ( "," event )* "]"
>

Keith, what I see is more like

   result ==>
      stuff  ( "," event ) *
   event ==>
      "MI_HOOK_RESULT=[HOOK_TYPE=" event-name [ event-data ] "]"

which you can verify, e.g. by running a user defined command that
creates 2 breakpoints, you get two MI_HOOK_RESULTs.

In Apple's (old) code these hooks are only enabled for the duration of an
-interpreter-exec console command.  That means there are several
ways a UI is notified of breakpoint creation

after -break-insert, you get
     ^done,bkpt=[number="1",type="breakpoint", ...]

after -interpreter-exec console "break ...", or
using -interpreter-exec to run a user defined command
or script that creates breakpoints, you are proposing
     ^done,event=[name="breakpoint_create", ...]

from a breakpoint command list (e.g. enable bkpt 2
after bkpt 1 is hit 100 times) ...
hmm, when MI is enabled these commands don't run
unless you also use --noasync, maybe bpstat_do_actions()
is not called from the event loop?
Anyway, when I do get them to run, there is no notification
at all.

As consumers, we would prefer to have one notification
that is reliable and consistent.


Are you also looking at the other, non-event hooks
Apple introduced?

query hook - always answers "y" to a "y or n" query
(seems a little scary)

read one line hook - If a console
command needs multiline input (e.g."define", "document",
"if", or "while), prompt with
     =read-one-line,prompt="prompt"
so the UI can know not to prepend "-interpreter-exec console"
to the next input line.

resume hook - if a console command attempts to run the target,
don't do it, instead send the notification
      =rerun
back to the UI, I guess so it can get out of "CLI mode" first.


Brian Thomson
IBM