[RFC] MI: Event notification

[RFC] MI: Event notification

[Nick Roberts]

This is another change based on Apple's work.  It is part of my focus on
improving responsivity of the frontend, along with the timing patch.

The general idea is to report changes in program state to the frontend so that
it only updates the parts that need it.  For example, after "up"
frame_changed_hook triggers and the frontend knows it has to update the locals
display.  This means that stepping through a single frame should be much
quicker.  If GDB enters a new frame during execution, stack_changed_hook
triggers and the frontend knows it has to update the call stack display.  I
would eventually like to add more hooks like target-changed-hook when the user
attaches to/detaches from a process, kills the process, or selects a new target
with the "file" command.
  
The hooks are inserted/removed through "interpreter-exec console cli-command"
so I envisage not using MI commands like -exec-run, -exec-next,
-stack-select-frame that change that state.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.198
diff -c -p -r1.198 defs.h
*** defs.h	21 Sep 2006 13:50:51 -0000	1.198
--- defs.h	1 Jan 2007 23:17:13 -0000
*************** extern void (*deprecated_show_load_progr
*** 1124,1129 ****
--- 1124,1136 ----
  extern void (*deprecated_print_frame_info_listing_hook) (struct symtab * s,
  							 int line, int stopline,
  							 int noerror);
+ 
+ /* called when the frame changes (e.g. as the result of "up") */
+ extern void (*frame_changed_hook) (int new_frame_number);
+ 
+ /* called when the stack changes (i.e. a new frame is added) */
+ extern void (*stack_changed_hook) (void);
+ 
  extern int (*deprecated_query_hook) (const char *, va_list)
       ATTRIBUTE_FPTR_PRINTF(1,0);
  extern void (*deprecated_warning_hook) (const char *, va_list)
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.215
diff -c -p -r1.215 frame.c
*** frame.c	10 Nov 2006 20:11:35 -0000	1.215
--- frame.c	1 Jan 2007 23:17:16 -0000
*************** select_frame (struct frame_info *fi)
*** 905,910 ****
--- 905,913 ----
    if (deprecated_selected_frame_level_changed_hook)
      deprecated_selected_frame_level_changed_hook (frame_relative_level (fi));
  
+   if (frame_changed_hook)
+     frame_changed_hook (frame_relative_level (fi));
+ 
    /* FIXME: kseitz/2002-08-28: It would be nice to call
       selected_frame_level_changed_event() right here, but due to limitations
       in the current interfaces, we would end up flooding UIs with events
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.217
diff -c -p -r1.217 infrun.c
*** infrun.c	30 Dec 2006 15:56:00 -0000	1.217
--- infrun.c	1 Jan 2007 23:17:25 -0000
*************** Further execution is probably impossible
*** 3084,3089 ****
--- 3084,3097 ----
  
    breakpoint_auto_delete (stop_bpstat);
  
+   if (!stop_stack_dummy)
+     {
+       if ((stack_changed_hook != NULL) &&
+ 	  (!frame_id_eq (step_frame_id, get_frame_id (get_current_frame ())) ||
+ 	   step_start_function != find_pc_function (stop_pc)))
+ 	stack_changed_hook ();
+     }
+ 
    /* If an auto-display called a function and that got a signal,
       delete that auto-display to avoid an infinite recursion.  */
  
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.140
diff -c -p -r1.140 stack.c
*** stack.c	18 Oct 2006 19:52:05 -0000	1.140
--- stack.c	1 Jan 2007 23:17:28 -0000
*************** If you continue, the return value that y
*** 1872,1877 ****
--- 1872,1880 ----
    if (get_frame_type (get_current_frame ()) == DUMMY_FRAME)
      frame_pop (get_current_frame ());
  
+   if (stack_changed_hook != NULL)
+     stack_changed_hook ();
+ 
    /* If interactive, print the frame that is now current.  */
    if (from_tty)
      frame_command ("0", 1);
Index: mi/mi-interp.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-interp.c,v
retrieving revision 1.17
diff -c -p -r1.17 mi-interp.c
*** mi/mi-interp.c	23 Dec 2005 18:57:46 -0000	1.17
--- mi/mi-interp.c	1 Jan 2007 23:17:29 -0000
*************** mi_cmd_interpreter_exec (char *command, 
*** 277,293 ****
--- 277,325 ----
   * the gdb CLI interpreter from within the MI, while still producing MI style output
   * when actions in the CLI command change gdb's state.
  */
+ void 
+ mi_interp_stack_changed_hook (void)
+ {
+   struct ui_out *uiout = interp_ui_out (NULL);
+   fprintf_unfiltered (raw_stdout, "%s", "=stack_changed");
+   mi_out_put (uiout, raw_stdout);
+   mi_out_rewind (uiout);
+   fputs_unfiltered ("\n", raw_stdout);
+   gdb_flush (raw_stdout);
+ }
+ 
+ void 
+ mi_interp_frame_changed_hook (int new_frame_number)
+ {
+   struct ui_out *uiout = interp_ui_out (NULL);
+ 
+   /* Don't report new_frame_number == -1, that is just the invalidate frame
+      message, and there is not much the UI can do with that.  */
+   if (new_frame_number == -1)
+     return;
+ 
+   fprintf_unfiltered (raw_stdout, "%s", "=frame_changed");
+   ui_out_field_int (uiout, "frame", new_frame_number);
+   mi_out_put (uiout, raw_stdout);
+   mi_out_rewind (uiout);
+   fputs_unfiltered ("\n", raw_stdout);
+   gdb_flush (raw_stdout);
+ }
  
  static void
  mi_insert_notify_hooks (void)
  {
    deprecated_query_hook = mi_interp_query_hook;
+   frame_changed_hook = mi_interp_frame_changed_hook;
+   stack_changed_hook = mi_interp_stack_changed_hook;
  }
  
  static void
  mi_remove_notify_hooks (void)
  {
    deprecated_query_hook = NULL;
+   frame_changed_hook = NULL;
+   stack_changed_hook = NULL;
  }
  
  static int

Re: [RFC] MI: Event notification

[Vladimir Prus]

Nick Roberts wrote:

> 
> This is another change based on Apple's work.  It is part of my focus on
> improving responsivity of the frontend, along with the timing patch.
> 
> The general idea is to report changes in program state to the frontend so
> that
> it only updates the parts that need it.  For example, after "up"
> frame_changed_hook triggers and the frontend knows it has to update the
> locals
> display.  

You mean, after "up" emitted explicitly by the user? If the frontend changes
the frame itself, it does not need any notifications.

> This means that stepping through a single frame should be much 
> quicker.  If GDB enters a new frame during execution, stack_changed_hook
> triggers and the frontend knows it has to update the call stack display. 
> I would eventually like to add more hooks like target-changed-hook when
> the user attaches to/detaches from a process, kills the process, or
> selects a new target with the "file" command.

Is this all for user-typed commands? I wonder if notifications for those
are really needed. Reloading entire UI state after a user command does
not seem too bad -- because user is not likely to enter 10 commands per second
anyway -- and is much simpler.

> The hooks are inserted/removed through "interpreter-exec console
> cli-command" 

Sorry, can you clarify?

> so I envisage not using MI commands like -exec-run, 
> -exec-next, -stack-select-frame that change that state.

Again, what do you mean?

- Volodya

Re: [RFC] MI: Event notification

[Nick Roberts]

 > > The general idea is to report changes in program state to the frontend so
 > > that it only updates the parts that need it.  For example, after "up"
 > > frame_changed_hook triggers and the frontend knows it has to update the
 > > locals display.
 > 
 > You mean, after "up" emitted explicitly by the user? If the frontend changes
 > the frame itself, it does not need any notifications.

It might not be by clicking on a button but by typing "up" or even "u" from
the console (GUD buffer).  In such a case how would the frontend know that
the frame has changed?

 > > This means that stepping through a single frame should be much 
 > > quicker.  If GDB enters a new frame during execution, stack_changed_hook
 > > triggers and the frontend knows it has to update the call stack display. 
 > > I would eventually like to add more hooks like target-changed-hook when
 > > the user attaches to/detaches from a process, kills the process, or
 > > selects a new target with the "file" command.
 > 
 > Is this all for user-typed commands? I wonder if notifications for those are
 > really needed. Reloading entire UI state after a user command does not seem
 > too bad -- because user is not likely to enter 10 commands per second anyway
 > -- and is much simpler.

With a large stack and stepping through the program, I think it is very
noticeable, which is why I frequently try to select a line to run to.

 > > The hooks are inserted/removed through "interpreter-exec console
 > > cli-command" 
 > 
 > Sorry, can you clarify?

In mi_cmd_interpreter_exec, there are calls to mi_insert_notify_hooks and
mi_remove_notify_hooks.

 > > so I envisage not using MI commands like -exec-run, 
 > > -exec-next, -stack-select-frame that change that state.

mi_cmd_interpreter_exec only gets called with "interpreter-exec" so there
would be no event notification in this case.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] MI: Event notification

[Vladimir Prus]

On Thursday 04 January 2007 23:49, Nick Roberts wrote:
>  > > The general idea is to report changes in program state to the frontend so
>  > > that it only updates the parts that need it.  For example, after "up"
>  > > frame_changed_hook triggers and the frontend knows it has to update the
>  > > locals display.
>  > 
>  > You mean, after "up" emitted explicitly by the user? If the frontend changes
>  > the frame itself, it does not need any notifications.
> 
> It might not be by clicking on a button but by typing "up" or even "u" from
> the console (GUD buffer).  In such a case how would the frontend know that
> the frame has changed?
> 
>  > > This means that stepping through a single frame should be much 
>  > > quicker.  If GDB enters a new frame during execution, stack_changed_hook
>  > > triggers and the frontend knows it has to update the call stack display. 
>  > > I would eventually like to add more hooks like target-changed-hook when
>  > > the user attaches to/detaches from a process, kills the process, or
>  > > selects a new target with the "file" command.
>  > 
>  > Is this all for user-typed commands? I wonder if notifications for those are
>  > really needed. Reloading entire UI state after a user command does not seem
>  > too bad -- because user is not likely to enter 10 commands per second anyway
>  > -- and is much simpler.
> 
> With a large stack and stepping through the program, I think it is very
> noticeable, which is why I frequently try to select a line to run to.

Stepping through the code and typing CLI commands are rather different
activities. For entering CLI, full UI state reload is not so problematic.

For stepping:

	1. I have a proposal for "-var-list --locals" that I think will
	make work with local variables very convenient and fast. I'll post
	that tomorrow.
	2. As for -stack-* -- if there any reason why that code cannot detect
	that stack has not changed and quickly return "cached" result.
	That will optimize all existing frontends automatically.
 
>  > > The hooks are inserted/removed through "interpreter-exec console
>  > > cli-command" 
>  > 
>  > Sorry, can you clarify?
> 
> In mi_cmd_interpreter_exec, there are calls to mi_insert_notify_hooks and
> mi_remove_notify_hooks.

Ok.

>  > > so I envisage not using MI commands like -exec-run, 
>  > > -exec-next, -stack-select-frame that change that state.
> 
> mi_cmd_interpreter_exec only gets called with "interpreter-exec" so there
> would be no event notification in this case.

I suppose frontend can check if the input starts with "-" and do full reload
in that case, anyway?

- Volodya

 

Re: [RFC] MI: Event notification

[Nick Roberts]

 > > With a large stack and stepping through the program, I think it is very
 > > noticeable, which is why I frequently try to select a line to run to.
 > 
 > Stepping through the code and typing CLI commands are rather different
 > activities. For entering CLI, full UI state reload is not so problematic.
 > 
 > For stepping:
 > 
 > 	1. I have a proposal for "-var-list --locals" that I think will
 > 	make work with local variables very convenient and fast. I'll post
 > 	that tomorrow.

OK, I'll look at that ( = "-stack-list-locals --create-varobjs"?).

 > 	2. As for -stack-* -- if there any reason why that code cannot detect
 > 	that stack has not changed and quickly return "cached" result.
 > 	That will optimize all existing frontends automatically.

I just wanted to start discussion, not commit the patch.  Let's review it
after you've posted your patch for "-var-list --locals"


-- 
Nick                                           http://www.inet.net.nz/~nickrob