[RFC] Using bt command in async mode

[RFC] Using bt command in async mode

[Nick Roberts]

This patch allows the bt to be executed in async mode while the inferior is
executing.  The idea being that the frontend can get a snapshot of what the
inferior is doing and update the UI.  It's just a proof of concept, so I've
used linux_nat_async_events and my_waitpid directly but eventually these could
be made into target methods, of course.

If the general idea is agreeable, I would like to extend it to other commands
like "info locals", "info threads" etc.

An example session looks like this:

 
    (gdb) maintenance set linux-async on
    (gdb) r&
    Starting program: /home/nickrob/donowt 
    (gdb) bt
    #0  0x080483c9 in mysub1 () at donowt.c:12
    #1  0x080483f7 in mysub () at donowt.c:22
    #2  0x0804840f in main () at donowt.c:28
    (gdb) interrupt
    (gdb) 
    Program received signal SIGINT, Interrupt.
    0x080483c9 in mysub1 () at donowt.c:12
    12            if (i == 5)

    (gdb) quit
    The program is running.  Quit anyway (and kill it)? (y or n) y
    nickrob@kahikatea:~$ 


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


2008-04-01  Nick Roberts  <nickrob@snap.net.nz>

	* stack.c (backtrace_command): Make it work in async mode when
	the target is executing.

	* top.c (execute_command): Enable bt command in async mode.

	* inferior.h: New externs

	* linux-nat.c (linux_nat_async_events, my_waitpid):  Make
	non-static.


*** stack.c	18 Mar 2008 08:32:24 +1200	1.164
--- stack.c	01 Apr 2008 12:58:57 +1200	
*************** static void
*** 1285,1293 ****
  backtrace_command (char *arg, int from_tty)
  {
    struct cleanup *old_chain = NULL;
!   int fulltrace_arg = -1, arglen = 0, argc = 0;
    struct backtrace_command_args btargs;
  
    if (arg)
      {
        char **argv;
--- 1285,1306 ----
  backtrace_command (char *arg, int from_tty)
  {
    struct cleanup *old_chain = NULL;
!   int fulltrace_arg = -1, arglen = 0, argc = 0, restart = 0;
    struct backtrace_command_args btargs;
  
+    if (target_executing)
+      {
+        int status, options, async_events_were_enabled;
+ 
+        /* Must be async to get here.  */
+        async_events_were_enabled = linux_nat_async_events (0);
+        target_stop ();
+        my_waitpid (PIDGET (inferior_ptid), &status, 0);
+        if (async_events_were_enabled)
+ 	 linux_nat_async_events (1);
+        restart = 1;
+      }
+ 
    if (arg)
      {
        char **argv;
*************** backtrace_command (char *arg, int from_t
*** 1342,1347 ****
--- 1355,1363 ----
  
    if (old_chain)
      do_cleanups (old_chain);
+ 
+   if (restart)
+     continue_command ("&", 0);
  }
  
  static void


*** top.c	01 Apr 2008 13:47:11 +1200	1.137
--- top.c	01 Apr 2008 13:35:00 +1200	
*************** execute_command (char *p, int from_tty)
*** 463,469 ****
  	    && strcmp (c->name, "pwd") != 0
  	    && strcmp (c->name, "show") != 0
  	    && strcmp (c->name, "info") != 0
! 	    && strcmp (c->name, "interrupt") != 0)
  	  error (_("Cannot execute this command while the target is running."));
  
        /* Pass null arg rather than an empty one.  */
--- 463,470 ----
  	    && strcmp (c->name, "pwd") != 0
  	    && strcmp (c->name, "show") != 0
  	    && strcmp (c->name, "info") != 0
! 	    && strcmp (c->name, "interrupt") != 0
! 	    && strcmp (c->name, "bt") != 0)
  	  error (_("Cannot execute this command while the target is running."));
  
        /* Pass null arg rather than an empty one.  */


*** inferior.h	30 Jan 2008 11:18:32 +1300	1.87
--- inferior.h	01 Apr 2008 09:24:04 +1200	
*************** struct regcache;
*** 49,54 ****
--- 49,57 ----
  
  struct inferior_status;
  
+ extern int my_waitpid (int pid, int *status, int flags);
+ extern int linux_nat_async_events (int enable);
+ 
  extern struct inferior_status *save_inferior_status (int);
  
  extern void restore_inferior_status (struct inferior_status *);

*** linux-nat.c	26 Mar 2008 08:51:33 +1200	1.80
--- linux-nat.c	01 Apr 2008 13:10:00 +1200	
*************** static volatile int linux_nat_num_queued
*** 176,182 ****
     target events are blocked.  */
  static int linux_nat_async_events_enabled;
  
- static int linux_nat_async_events (int enable);
  static void pipe_to_local_event_queue (void);
  static void local_event_queue_to_pipe (void);
  static void linux_nat_event_pipe_push (int pid, int status, int options);
--- 176,181 ----
*************** linux_tracefork_child (void)
*** 350,356 ****
  /* Wrapper function for waitpid which handles EINTR, and checks for
     locally queued events.  */
  
! static int
  my_waitpid (int pid, int *status, int flags)
  {
    int ret;
--- 349,355 ----
  /* Wrapper function for waitpid which handles EINTR, and checks for
     locally queued events.  */
  
! int
  my_waitpid (int pid, int *status, int flags)
  {
    int ret;
*************** async_sigchld_handler (int signo)
*** 3820,3826 ****
  
  /* Enable or disable async SIGCHLD handling.  */
  
! static int
  linux_nat_async_events (int enable)
  {
    int current_state = linux_nat_async_events_enabled;
--- 3819,3825 ----
  
  /* Enable or disable async SIGCHLD handling.  */
  
! int
  linux_nat_async_events (int enable)
  {
    int current_state = linux_nat_async_events_enabled;

Re: [RFC] Using bt command in async mode

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> This patch allows the bt to be executed in async mode while the
Nick> inferior is executing.

Nick> ! 	    && strcmp (c->name, "interrupt") != 0
Nick> ! 	    && strcmp (c->name, "bt") != 0)

I've seen a couple patches recently that touch this conditional.

What do you think of this?  It moves the flag into the command object
instead of hard-coding it into a big 'if'.

I'm running the test suite now.

Tom

ChangeLog:
2008-04-01  Tom Tromey  <tromey@redhat.com>

	* cli/cli-decode.h (CMD_ASYNC_OK): New define.
	(set_cmd_async_ok, get_cmd_async_ok): Declare.
	* cli/cli-decode.c (set_cmd_async_ok): New function.
	(get_cmd_async_ok): New function.
	* cli/cli-cmds.c (init_cli_cmds): Mark "pwd", "help", "info", and
	"show" as async-ok.
	* top.c (execute_command): Use get_cmd_async_ok.
	* infcmd.c: Include cli/cli-decode.h.
	(_initialize_infcmd): Mark "interrupt" as async-ok.
	* Makefile.in (infcmd.o): Depend on cli_decode_h.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.996
diff -u -r1.996 Makefile.in
--- Makefile.in	26 Mar 2008 14:53:28 -0000	1.996
+++ Makefile.in	1 Apr 2008 18:38:21 -0000
@@ -2291,7 +2291,7 @@
 	$(objfiles_h) $(completer_h) $(ui_out_h) $(event_top_h) \
 	$(parser_defs_h) $(regcache_h) $(reggroups_h) $(block_h) \
 	$(solib_h) $(gdb_assert_h) $(observer_h) $(target_descriptions_h) \
-	$(user_regs_h) $(exceptions_h)
+	$(user_regs_h) $(exceptions_h) $(cli_decode_h)
 inf-loop.o: inf-loop.c $(defs_h) $(inferior_h) $(target_h) $(event_loop_h) \
 	$(event_top_h) $(inf_loop_h) $(remote_h) $(exceptions_h) \
 	$(language_h)
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.174
diff -u -r1.174 infcmd.c
--- infcmd.c	17 Mar 2008 17:30:29 -0000	1.174
+++ infcmd.c	1 Apr 2008 18:38:21 -0000
@@ -49,6 +49,7 @@
 #include "target-descriptions.h"
 #include "user-regs.h"
 #include "exceptions.h"
+#include "cli/cli-decode.h"
 
 /* Functions exported for general use, in inferior.h: */
 
@@ -2326,8 +2327,9 @@
 \"run\" command."));
   set_cmd_completer (c, filename_completer);
 
-  add_com ("interrupt", class_run, interrupt_target_command,
-	   _("Interrupt the execution of the debugged program."));
+  c = add_com ("interrupt", class_run, interrupt_target_command,
+	       _("Interrupt the execution of the debugged program."));
+  set_cmd_async_ok (c);
 
   add_info ("registers", nofp_registers_info, _("\
 List of integer registers and their contents, for selected stack frame.\n\
Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.137
diff -u -r1.137 top.c
--- top.c	23 Mar 2008 17:29:34 -0000	1.137
+++ top.c	1 Apr 2008 18:38:21 -0000
@@ -458,13 +458,8 @@
 
       /* If the target is running, we allow only a limited set of
          commands. */
-      if (target_can_async_p () && target_executing)
-	if (strcmp (c->name, "help") != 0
-	    && strcmp (c->name, "pwd") != 0
-	    && strcmp (c->name, "show") != 0
-	    && strcmp (c->name, "info") != 0
-	    && strcmp (c->name, "interrupt") != 0)
-	  error (_("Cannot execute this command while the target is running."));
+      if (target_can_async_p () && target_executing && !get_cmd_async_ok (c))
+	error (_("Cannot execute this command while the target is running."));
 
       /* Pass null arg rather than an empty one.  */
       arg = *p ? p : 0;
Index: cli/cli-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.73
diff -u -r1.73 cli-cmds.c
--- cli/cli-cmds.c	1 Jan 2008 22:53:14 -0000	1.73
+++ cli/cli-cmds.c	1 Apr 2008 18:38:21 -0000
@@ -1202,8 +1202,9 @@
 
   /* Define general commands. */
 
-  add_com ("pwd", class_files, pwd_command, _("\
+  c = add_com ("pwd", class_files, pwd_command, _("\
 Print working directory.  This is used for your program as well."));
+  set_cmd_async_ok (c);
   c = add_cmd ("cd", class_files, cd_command, _("\
 Set working directory to DIR for debugger and program being debugged.\n\
 The change does not take effect for the program being debugged\n\
@@ -1243,6 +1244,7 @@
   c = add_com ("help", class_support, help_command,
 	       _("Print list of commands."));
   set_cmd_completer (c, command_completer);
+  set_cmd_async_ok (c);
   add_com_alias ("q", "quit", class_support, 1);
   add_com_alias ("h", "help", class_support, 1);
 
@@ -1268,17 +1270,19 @@
 			   show_history_expansion_p,
 			   &sethistlist, &showhistlist);
 
-  add_prefix_cmd ("info", class_info, info_command, _("\
+  c = add_prefix_cmd ("info", class_info, info_command, _("\
 Generic command for showing things about the program being debugged."),
-		  &infolist, "info ", 0, &cmdlist);
+		      &infolist, "info ", 0, &cmdlist);
+  set_cmd_async_ok (c);
   add_com_alias ("i", "info", class_info, 1);
 
   add_com ("complete", class_obscure, complete_command,
 	   _("List the completions for the rest of the line as a command."));
 
-  add_prefix_cmd ("show", class_info, show_command,
-		  _("Generic command for showing things about the debugger."),
-		  &showlist, "show ", 0, &cmdlist);
+  c = add_prefix_cmd ("show", class_info, show_command, _("\
+Generic command for showing things about the debugger."),
+		      &showlist, "show ", 0, &cmdlist);
+  set_cmd_async_ok (c);
   /* Another way to get at the same thing.  */
   add_info ("set", show_command, _("Show all GDB settings."));
 
Index: cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.63
diff -u -r1.63 cli-decode.c
--- cli/cli-decode.c	1 Jan 2008 22:53:14 -0000	1.63
+++ cli/cli-decode.c	1 Apr 2008 18:38:22 -0000
@@ -105,6 +105,18 @@
   return cmd->context;
 }
 
+void
+set_cmd_async_ok (struct cmd_list_element *cmd)
+{
+  cmd->flags |= CMD_ASYNC_OK;
+}
+
+int
+get_cmd_async_ok (struct cmd_list_element *cmd)
+{
+  return cmd->flags & CMD_ASYNC_OK;
+}
+
 enum cmd_types
 cmd_type (struct cmd_list_element *cmd)
 {
Index: cli/cli-decode.h
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.h,v
retrieving revision 1.27
diff -u -r1.27 cli-decode.h
--- cli/cli-decode.h	1 Jan 2008 22:53:14 -0000	1.27
+++ cli/cli-decode.h	1 Apr 2008 18:38:22 -0000
@@ -48,6 +48,9 @@
 #define DEPRECATED_WARN_USER      0x2
 #define MALLOCED_REPLACEMENT      0x4
 
+/* This flag is set if the command is allowed during async execution.  */
+#define CMD_ASYNC_OK              0x8
+
 struct cmd_list_element
   {
     /* Points to next command in this list.  */
@@ -243,6 +246,13 @@
 extern void set_cmd_context (struct cmd_list_element *cmd, void *context);
 extern void *get_cmd_context (struct cmd_list_element *cmd);
 
+/* Mark command as async-ready; there is no way to disable this once
+   set.  */
+extern void set_cmd_async_ok (struct cmd_list_element *);
+
+/* Return true if command is async-ok.  */
+extern int get_cmd_async_ok (struct cmd_list_element *);
+
 extern struct cmd_list_element *lookup_cmd (char **,
 					    struct cmd_list_element *, char *,
 					    int, int);

Re: [RFC] Using bt command in async mode

[Nick Roberts]

 > Nick> This patch allows the bt to be executed in async mode while the
 > Nick> inferior is executing.
 > 
 > Nick> ! 	    && strcmp (c->name, "interrupt") != 0
 > Nick> ! 	    && strcmp (c->name, "bt") != 0)
 > 
 > I've seen a couple patches recently that touch this conditional.
 > 
 > What do you think of this?  It moves the flag into the command object
 > instead of hard-coding it into a big 'if'.

Sure, the list will only get longer.  In the long run it might be a good
idea to add an argument to add_cmd and related functions.

Incidentally, the patch I've presented for bt isn't suitable for inclusion
as it uses:

+ 
+   if (restart)
+     continue_command ("&", 0);

If the user interrupts with 'bt' during a step, he presumably wants the step to
finish.  I'm not sure how easy it is for Gdb to jump the inferior back into
it's old state of execution.

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

Re: [RFC] Using bt command in async mode

[Daniel Jacobowitz]

On Tue, Apr 01, 2008 at 11:53:52AM -0600, Tom Tromey wrote:
> What do you think of this?  It moves the flag into the command object
> instead of hard-coding it into a big 'if'.

Seems like this will be just as awkward in the long term, but it's an
improvement.  OK if it tested fine.

> ChangeLog:
> 2008-04-01  Tom Tromey  <tromey@redhat.com>
> 
> 	* cli/cli-decode.h (CMD_ASYNC_OK): New define.
> 	(set_cmd_async_ok, get_cmd_async_ok): Declare.
> 	* cli/cli-decode.c (set_cmd_async_ok): New function.
> 	(get_cmd_async_ok): New function.
> 	* cli/cli-cmds.c (init_cli_cmds): Mark "pwd", "help", "info", and
> 	"show" as async-ok.
> 	* top.c (execute_command): Use get_cmd_async_ok.
> 	* infcmd.c: Include cli/cli-decode.h.
> 	(_initialize_infcmd): Mark "interrupt" as async-ok.
> 	* Makefile.in (infcmd.o): Depend on cli_decode_h.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Using bt command in async mode

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> Seems like this will be just as awkward in the long term, but
Daniel> it's an improvement.

Is there some other approach you'd prefer?

Daniel> OK if it tested fine.

I didn't run the test suite without the patch; I'll do that next week
& check it in if it looks ok.

Tom

Re: [RFC] Using bt command in async mode

[Pedro Alves]

A Thursday 10 April 2008 16:22:36, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
>
> Daniel> Seems like this will be just as awkward in the long term, but
> Daniel> it's an improvement.
>
> Is there some other approach you'd prefer?
>

The approach I though of following would be to
do it explicitly in each command, given that we
may have commands that may apply to another thread
not the current one in non-stop mode, prohibiting those
commands early may be wrong.

Something similar to ERROR_NO_INFERIOR.

I'm not sure we're settled on --thread or not, so
I didn't come forward with this.

-- 
Pedro Alves

Re: [RFC] Using bt command in async mode

[Daniel Jacobowitz]

On Thu, Apr 10, 2008 at 09:22:36AM -0600, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
> 
> Daniel> Seems like this will be just as awkward in the long term, but
> Daniel> it's an improvement.
> 
> Is there some other approach you'd prefer?

Not that I can think of.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Using bt command in async mode

[Vladimir Prus]

Nick Roberts wrote:

>  > Nick> This patch allows the bt to be executed in async mode while the
>  > Nick> inferior is executing.
>  > 
>  > Nick> !        && strcmp (c->name, "interrupt") != 0
>  > Nick> !        && strcmp (c->name, "bt") != 0)
>  > 
>  > I've seen a couple patches recently that touch this conditional.
>  > 
>  > What do you think of this?  It moves the flag into the command object
>  > instead of hard-coding it into a big 'if'.
> 
> Sure, the list will only get longer.  In the long run it might be a good
> idea to add an argument to add_cmd and related functions.
> 
> Incidentally, the patch I've presented for bt isn't suitable for inclusion
> as it uses:
> 
> +
> +   if (restart)
> +     continue_command ("&", 0);
> 
> If the user interrupts with 'bt' during a step, he presumably wants the step to
> finish.  I'm not sure how easy it is for Gdb to jump the inferior back into
> it's old state of execution.

It's not very hard. You only need to hack continue_command not to call (indirectly)
the clear_proceed_status function, which currently wipes away all state.

- Volodya

Re: [RFC] Using bt command in async mode

[Nick Roberts]

 > > Incidentally, the patch I've presented for bt isn't suitable for inclusion
 > > as it uses:
 > > 
 > > +
 > > +   if (restart)
 > > +     continue_command ("&", 0);
 > > 
 > > If the user interrupts with 'bt' during a step, he presumably wants the
 > > step to finish.  I'm not sure how easy it is for Gdb to jump the inferior
 > > back into it's old state of execution.
 > 
 > It's not very hard. You only need to hack continue_command not to call
 > (indirectly) the clear_proceed_status function, which currently wipes away
 > all state.

It looks a bit harder than that.  Perhaps the arguments proceed () was called
with need to be saved, as well as executing the appropriate contination
after proceed () returns.

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

Re: [RFC] Using bt command in async mode

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Daniel> OK if it tested fine.

Tom> I didn't run the test suite without the patch; I'll do that next week
Tom> & check it in if it looks ok.

I ran this and there were no regressions.
I will check it in shortly.

Tom

Re: [RFC] Using bt command in async mode

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

>> Is there some other approach you'd prefer?

Pedro> The approach I though of following would be to
Pedro> do it explicitly in each command, given that we
Pedro> may have commands that may apply to another thread
Pedro> not the current one in non-stop mode, prohibiting those
Pedro> commands early may be wrong.

Pedro> Something similar to ERROR_NO_INFERIOR.

Pedro> I'm not sure we're settled on --thread or not, so
Pedro> I didn't come forward with this.

I think this can still work with the patch I'm committing.  A command
that is ok for async could dynamically decide that it is not ok and
throw an error.

Tom