[RFA] Allow to enable run/stop notifications for function calls.

[RFA] Allow to enable run/stop notifications for function calls.

[Vladimir Prus]

I've already posted patches to produce more accurate *stopped notifications
in MI and introduce *running notification.  Those notification are not produced
during inferior function calls, as it's very likely than an unprepared frontend
will try to refetch everything in response to those *stopped, re-evaluating all
expression again, calling functions again, etc.

This patch allows a frontend to request the notification for function
calls to be still emitted, by using

  -enable-feature infcall-run-stop-notifications

OK?

- Volodya

	* infcall.c (suppress_run_stop_observers_during_infcall): New.
	(call_function_by_hand): Use
	suppress_run_stop_observers_during_infcall.
	* inferior.h (suppress_run_stop_observers_during_infcall):
	Declare.
	* mi/mi-cmds.c (mi_cmds): Register "enable-feature".
	* mi/mi-cmds.h (mi_cmd_enable_feature): Declare.
	* mi/mi-main.c (mi_cmd_enable_feature): New.
	(mi_cmd_list_features): Report "infcall-run-stop-notifications".
---
 gdb/infcall.c    |    5 ++++-
 gdb/inferior.h   |    4 ++++
 gdb/mi/mi-cmds.c |    1 +
 gdb/mi/mi-cmds.h |    1 +
 gdb/mi/mi-main.c |   17 +++++++++++++++++
 5 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/gdb/infcall.c b/gdb/infcall.c
index 28408ec..95f1292 100644
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -42,6 +42,8 @@
    asynchronous inferior function call implementation, and that in
    turn means restructuring the code so that it is event driven.  */
 
+int suppress_run_stop_observers_during_infcall = 1;
+
 /* How you should pass arguments to a function depends on whether it
    was defined in K&R style or prototype style.  If you define a
    function using the K&R syntax that takes a `float' argument, then
@@ -721,7 +723,8 @@ call_function_by_hand (struct value *function, int nargs, struct value **args)
       saved_async = target_async_mask (0);
 
     old_cleanups2 = make_cleanup_restore_integer 
-      (&suppress_run_stop_observers, 1);
+      (&suppress_run_stop_observers, 
+       suppress_run_stop_observers_during_infcall);
     proceed (real_pc, TARGET_SIGNAL_0, 0);
     do_cleanups (old_cleanups2);
     
diff --git a/gdb/inferior.h b/gdb/inferior.h
index 8958aef..9215426 100644
--- a/gdb/inferior.h
+++ b/gdb/inferior.h
@@ -402,6 +402,10 @@ void displaced_step_dump_bytes (struct ui_file *file,
 
 /* When set, normal_stop will not call the normal_stop observer.  */
 extern int suppress_run_stop_observers;
+
+/* Controls if infrun.c should suppress run and stop observers when doing 
+   inferior function call.  */
+extern int suppress_run_stop_observers_during_infcall;
 \f
 /* Possible values for gdbarch_call_dummy_location.  */
 #define ON_STACK 1
diff --git a/gdb/mi/mi-cmds.c b/gdb/mi/mi-cmds.c
index e94648b..082c584 100644
--- a/gdb/mi/mi-cmds.c
+++ b/gdb/mi/mi-cmds.c
@@ -51,6 +51,7 @@ struct mi_cmd mi_cmds[] =
   { "data-read-memory", { NULL, 0 }, mi_cmd_data_read_memory},
   { "data-write-memory", { NULL, 0 }, mi_cmd_data_write_memory},
   { "data-write-register-values", { NULL, 0 }, mi_cmd_data_write_register_values},
+  { "enable-feature", { NULL, 0 }, mi_cmd_enable_feature},
   { "enable-timings", { NULL, 0 }, mi_cmd_enable_timings},
   { "environment-cd", { NULL, 0 }, mi_cmd_env_cd},
   { "environment-directory", { NULL, 0 }, mi_cmd_env_dir},
diff --git a/gdb/mi/mi-cmds.h b/gdb/mi/mi-cmds.h
index 087b5e4..8b0bb11 100644
--- a/gdb/mi/mi-cmds.h
+++ b/gdb/mi/mi-cmds.h
@@ -62,6 +62,7 @@ extern mi_cmd_argv_ftype mi_cmd_data_list_changed_registers;
 extern mi_cmd_argv_ftype mi_cmd_data_read_memory;
 extern mi_cmd_argv_ftype mi_cmd_data_write_memory;
 extern mi_cmd_argv_ftype mi_cmd_data_write_register_values;
+extern mi_cmd_argv_ftype mi_cmd_enable_feature;
 extern mi_cmd_argv_ftype mi_cmd_enable_timings;
 extern mi_cmd_argv_ftype mi_cmd_env_cd;
 extern mi_cmd_argv_ftype mi_cmd_env_dir;
diff --git a/gdb/mi/mi-main.c b/gdb/mi/mi-main.c
index 206b2c9..5281c7f 100644
--- a/gdb/mi/mi-main.c
+++ b/gdb/mi/mi-main.c
@@ -977,6 +977,22 @@ mi_cmd_data_write_memory (char *command, char **argv, int argc)
 }
 
 enum mi_cmd_result
+mi_cmd_enable_feature (char *command, char **argv, int argc)
+{
+  if (argc != 1)
+    error ("Usage: <feature-name>");
+
+  if (strcmp (argv[0], "infcall-run-stop-notification") == 0)
+    {
+      suppress_run_stop_observers_during_infcall = 0;
+    }
+  else
+    error ("Unknown feature name");
+    
+  return MI_CMD_DONE;
+}
+
+enum mi_cmd_result
 mi_cmd_enable_timings (char *command, char **argv, int argc)
 {
   if (argc == 0)
@@ -1011,6 +1027,7 @@ mi_cmd_list_features (char *command, char **argv, int argc)
       ui_out_field_string (uiout, NULL, "frozen-varobjs");
       ui_out_field_string (uiout, NULL, "pending-breakpoints");
       ui_out_field_string (uiout, NULL, "thread-info");
+      ui_out_field_string (uiout, NULL, "infcall-run-stop-notification");
       
       do_cleanups (cleanup);
 
-- 
1.5.3.5

Re: [RFA] Allow to enable run/stop notifications for function calls.

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Thu, 1 May 2008 17:51:48 +0400
> 
> 
> This patch allows a frontend to request the notification for function
> calls to be still emitted, by using
> 
>   -enable-feature infcall-run-stop-notifications
> 
> OK?

Should we document it?

Re: [RFA] Allow to enable run/stop notifications for function calls.

[Daniel Jacobowitz]

On Thu, May 01, 2008 at 05:51:48PM +0400, Vladimir Prus wrote:
> 
> I've already posted patches to produce more accurate *stopped notifications
> in MI and introduce *running notification.  Those notification are not produced
> during inferior function calls, as it's very likely than an unprepared frontend
> will try to refetch everything in response to those *stopped, re-evaluating all
> expression again, calling functions again, etc.
> 
> This patch allows a frontend to request the notification for function
> calls to be still emitted, by using
> 
>   -enable-feature infcall-run-stop-notifications
> 
> OK?

I'm still not convinced we need -enable-feature for anything that
-gdb-set and -gdb-show can not handle.

What do you think about bundling this sort of update into MI version
3?  That cuts down on the number of possible knobs for output, which
is IMO important.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] Allow to enable run/stop notifications for function calls.

[Vladimir Prus]

On Friday 02 May 2008 19:59:07 Daniel Jacobowitz wrote:
> On Thu, May 01, 2008 at 05:51:48PM +0400, Vladimir Prus wrote:
> > 
> > I've already posted patches to produce more accurate *stopped notifications
> > in MI and introduce *running notification.  Those notification are not produced
> > during inferior function calls, as it's very likely than an unprepared frontend
> > will try to refetch everything in response to those *stopped, re-evaluating all
> > expression again, calling functions again, etc.
> > 
> > This patch allows a frontend to request the notification for function
> > calls to be still emitted, by using
> > 
> >   -enable-feature infcall-run-stop-notifications
> > 
> > OK?
> 
> I'm still not convinced we need -enable-feature for anything that
> -gdb-set and -gdb-show can not handle.

Is -gdb-show output specified in any way? Is it subject to i18n?

> What do you think about bundling this sort of update into MI version
> 3?  That cuts down on the number of possible knobs for output, which
> is IMO important.

Well, this might be good idea, provided everybody concerned agree that
MI3 will be rapidly changing until futher notice and *no* compatibility
will be guaranteed until that point.

- Volodya


 

Re: [RFA] Allow to enable run/stop notifications for function calls.

[Daniel Jacobowitz]

On Fri, May 02, 2008 at 08:02:55PM +0400, Vladimir Prus wrote:
> > I'm still not convinced we need -enable-feature for anything that
> > -gdb-set and -gdb-show can not handle.
> 
> Is -gdb-show output specified in any way? Is it subject to i18n?

Good point.  For settings we expect MI clients to be interested in,
we could use the ui_out mechanism to give them named fields.  I think
that will work fine.

> > What do you think about bundling this sort of update into MI version
> > 3?  That cuts down on the number of possible knobs for output, which
> > is IMO important.
> 
> Well, this might be good idea, provided everybody concerned agree that
> MI3 will be rapidly changing until futher notice and *no* compatibility
> will be guaranteed until that point.

I think that's fine, if we think we can settle it down by the next
release.  Or the first release to fully support non-stop and async,
if that's not in time for the next release.  At some point we will
have to lock it in place, like we did for mi2.

Existing clients should be using mi2.  Some are probably just using
-i=mi, but that's an easy bug to fix.

-- 
Daniel Jacobowitz
CodeSourcery