reduce stop time at attach&

[Duy Nguyen <pclouds@gmail.com>]

Attaching non-stop + async on extended-remote target could be slow. In
my tests it could take up to half a second, which is too long for some
applications where they are expected to have execution time every 50ms
or so, otherwise things (in other parts of the system) break down. I
wonder if we can reduce stop time in this case?

From what I can see (and I know very little about gdb or debuggers in
general), in remote non-stop/async mode, we can resume execution
before doing post-attach actions. This keeps stop time down to about
15ms in my tests. The only problematic part is breakpoint
installation, which maybe could be done manually after the user
chooses a safe thread to stop. Something like this patch below
demonstrates it. Do you think there is any problem with it?

Another approach I'm toying with is allow the user to select a thread
to stop. This will be an idle thread, created for gdb to stop and
nothing else. So we could stop the first thread, lookup thread-db,
then resume it and stop the user-requested thread before doing the
rest of attaching. Or we could stop the user-requested thread right
away. Either way seems to be more complicated than just resuming as
soon as possible.

-- 8< --
diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 54aa1ef..7470a19 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -420,7 +420,8 @@ post_create_inferior (struct target_ops *target, int from_tty)
   stop_pc = 0;
   TRY
     {
-      stop_pc = regcache_read_pc (get_current_regcache ());
+      if (!target_is_async_p ())
+	stop_pc = regcache_read_pc (get_current_regcache ());
     }
   CATCH (ex, RETURN_MASK_ERROR)
     {
@@ -2609,19 +2610,9 @@ proceed_after_attach (int pid)
   do_cleanups (old_chain);
 }
 
-/* attach_command --
-   takes a program started up outside of gdb and ``attaches'' to it.
-   This stops it cold in its tracks and allows us to start debugging it.
-   and wait for the trace-trap that results from attaching.  */
-
 static void
-attach_command_post_wait (char *args, int from_tty, int async_exec)
+post_attach (int from_tty)
 {
-  struct inferior *inferior;
-
-  inferior = current_inferior ();
-  inferior->control.stop_soon = NO_STOP_QUIETLY;
-
   /* If no exec file is yet known, try to determine it from the
      process itself.  */
   if (get_exec_file (0) == NULL)
@@ -2636,6 +2627,20 @@ attach_command_post_wait (char *args, int from_tty, int async_exec)
   target_post_attach (ptid_get_pid (inferior_ptid));
 
   post_create_inferior (&current_target, from_tty);
+}
+
+/* attach_command --
+   takes a program started up outside of gdb and ``attaches'' to it.
+   This stops it cold in its tracks and allows us to start debugging it.
+   and wait for the trace-trap that results from attaching.  */
+
+static void
+attach_command_post_wait (char *args, int from_tty, int async_exec)
+{
+  struct inferior *inferior;
+
+  inferior = current_inferior ();
+  inferior->control.stop_soon = NO_STOP_QUIETLY;
 
   if (async_exec)
     {
@@ -2656,9 +2661,11 @@ attach_command_post_wait (char *args, int from_tty, int async_exec)
 	      proceed ((CORE_ADDR) -1, GDB_SIGNAL_DEFAULT);
 	    }
 	}
+      post_attach (from_tty);
     }
   else
     {
+      post_attach (from_tty);
       /* The user requested a plain `attach', so be sure to leave
 	 the inferior stopped.  */
 
-- 8< --