Re: [MI] Synchronous event notification

Re: [MI] Synchronous event notification

[thomson]

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

Re: [MI] Synchronous event notification

[Keith Seitz]

On Fri, 24 May 2002 thomson@ca.ibm.com wrote:

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

Yes, that's right. My boo-boo.

> 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) ...

Right. See my follow-up message to Andrew. I would like to reduce this all
to async event notification. (Well, initially we'll probably just leave
this specific thing alone. MI parsers could just ignore it.)

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

Me, too. :-)

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

I will be eventually. Right now it's back to basics. All the hooks will be
turned into events (as far as possible).

Keith

[MI] Synchronous event notification

[Keith Seitz]

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

Re: [MI] Synchronous event notification

[Andrew Cagney]

(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

Re: [MI] Synchronous event notification

[Keith Seitz]

On Fri, 24 May 2002, Andrew Cagney wrote:

> 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.

It has that as an advantage, but it also has one minor disadvantage: we'd
be processing events for synchronous targets and async targets
differently.

> 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?)

YES! This is exactly what I would prefer to see done. _All_ events come
out on a channel. Then it won't matter if the target is sync or async:
events are async in nature:

(gdb)
-interpreter-exec console "break foo"
&Breakpoint 1, ...
*breakpoint-create,bkpt=...
(gdb)
-break-insert main
*breakpoint-create,bkpt=...
(gdb)

UIs prefer to respond to events when something happens. In the later case
above, we've asked gdb to install a breakpoint at main, but the UI won't
actually do anything (like update breakpoint markers or breakpoint
windows) UNTILL it gets the event from gdb.

So, if we need to vote, I vote that we output aync events all the time.
(Of course, this would mean we really need to get target output nailed
for the natives, but that's another battle.)

Keith

Re: [MI] Synchronous event notification

[Andrew Cagney]

> UIs prefer to respond to events when something happens. In the later case
> above, we've asked gdb to install a breakpoint at main, but the UI won't
> actually do anything (like update breakpoint markers or breakpoint
> windows) UNTILL it gets the event from gdb.
> 
> So, if we need to vote, I vote that we output aync events all the time.
> (Of course, this would mean we really need to get target output nailed
> for the natives, but that's another battle.)

I don't think a vote is needed - it matches the original MI intent.  All 
events were to be considered considered async.

Andrew