[rfc] 'thread tid' command

[rfc] 'thread tid' command

[Michael Snyder]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

This is purposefully rough, 'cause I hope for discussion.

This is a new command to help manage large thread lists.
I started with the idea "I want to find out which thread
has target id 12345", then extended it to also handle the
new concept of thread names (which thread has name 'foo'),
and extra info as well (which thread has extra info that
includes the string "xyz").

The syntax (I'm open to renaming etc.):

   thread tid [NAME | TARGET_ID | EXTRA_INFO]


The output:

   Thread %d has name '%s'  or
   Thread %d has target id '%s' or
   Thread %d has extra info '%s'

The user can then use the given thread id as input to the
thread command, info threads, etc.

Comments?


[-- Attachment #2: tid.txt --]
[-- Type: text/plain, Size: 1966 bytes --]

Index: thread.c
===================================================================
RCS file: /cvs/src/src/gdb/thread.c,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 thread.c
--- thread.c	19 Jan 2011 17:21:36 -0000	1.131
+++ thread.c	11 Feb 2011 22:03:31 -0000
@@ -1313,6 +1323,34 @@ thread_name_command (char *arg, int from
   info->name = arg ? xstrdup (arg) : NULL;
 }
 
+/* Show thread ids with a name, target pid, or extra info matching ARG.  */
+
+static void
+tid_command (char *arg, int from_tty)
+{
+  struct thread_info *tp;
+  char *tmp;
+
+  if (arg == NULL || *arg == '\0')
+    error (_("Command requires an argument."));
+
+  update_thread_list ();
+
+  for (tp = thread_list; tp; tp = tp->next)
+    {
+      if (tp->name != NULL && strcmp (arg, tp->name) == 0)
+	printf_filtered ("Thread %d has name '%s'\n", tp->num, tp->name);
+
+      tmp = target_pid_to_str (tp->ptid);
+      if (tmp != NULL && strstr (tmp, arg) != 0)
+	printf_filtered ("Thread %d has target id '%s'\n", tp->num, tmp);
+
+      tmp = target_extra_thread_info (tp);
+      if (tmp != NULL && strstr (tmp, arg) != 0)
+	printf_filtered ("Thread %d has extra info '%s'\n", tp->num, tmp);
+    }
+}
+
 /* Print notices when new threads are attached and detached.  */
 int print_thread_events = 1;
 static void
@@ -1418,11 +1460,15 @@ The new thread ID must be currently know
   add_cmd ("all", class_run, thread_apply_all_command,
 	   _("Apply a command to all threads."), &thread_apply_list);
 
-  add_cmd ("name", class_run, thread_name_command,
+  add_cmd ("name", no_class, thread_name_command,
 	   _("Set the current thread's name.\n\
 Usage: thread name [NAME]\n\
 If NAME is not given, then any existing name is removed."), &thread_cmd_list);
 
+  add_cmd ("tid", no_class, tid_command, _("\
+Show thread ids with a name, target pid, or extra info matching ARG."),
+	   &thread_cmd_list);
+
   if (!xdb_commands)
     add_com_alias ("t", "thread", class_run, 1);
 

Re: [rfc] 'thread tid' command

[Pedro Alves]

On Friday 11 February 2011 22:12:39, Michael Snyder wrote:
> This is purposefully rough, 'cause I hope for discussion.
> 
> This is a new command to help manage large thread lists.
> I started with the idea "I want to find out which thread
> has target id 12345", then extended it to also handle the
> new concept of thread names (which thread has name 'foo'),
> and extra info as well (which thread has extra info that
> includes the string "xyz").
> 
> The syntax (I'm open to renaming etc.):
> 
>    thread tid [NAME | TARGET_ID | EXTRA_INFO]

Shouldn't this be under "info" or "show"?

> The output:
> 
>    Thread %d has name '%s'  or
>    Thread %d has target id '%s' or
>    Thread %d has extra info '%s'
> 
> The user can then use the given thread id as input to the
> thread command, info threads, etc.
> 
> Comments?

I think that if you made this accept a regex, it'll
end up being much more useful.  Particularly, to filter
the extra info fields.  Another interesting filter
could be: threads stopped in "foo_regex" function,
or address.

But still, the user will still have to manually pick
the output of the previous command.  I think it'd even
be better if the command had a switch that created a
thread group (itset or thread set, whatever) from the threads
that matched.  Only problem is we don't have thread
sets support, yet.

-- 
Pedro Alves

Re: [rfc] 'thread tid' command

[Michael Snyder]

Pedro Alves wrote:
> On Friday 11 February 2011 22:12:39, Michael Snyder wrote:
>> This is purposefully rough, 'cause I hope for discussion.
>>
>> This is a new command to help manage large thread lists.
>> I started with the idea "I want to find out which thread
>> has target id 12345", then extended it to also handle the
>> new concept of thread names (which thread has name 'foo'),
>> and extra info as well (which thread has extra info that
>> includes the string "xyz").
>>
>> The syntax (I'm open to renaming etc.):
>>
>>    thread tid [NAME | TARGET_ID | EXTRA_INFO]
> 
> Shouldn't this be under "info" or "show"?

Suits me, but
1) I'd prefer it wasn't "show", because there is no "set".
2) Info what?  tid?  thread-id?

> 
>> The output:
>>
>>    Thread %d has name '%s'  or
>>    Thread %d has target id '%s' or
>>    Thread %d has extra info '%s'
>>
>> The user can then use the given thread id as input to the
>> thread command, info threads, etc.
>>
>> Comments?
> 
> I think that if you made this accept a regex, it'll
> end up being much more useful.  Particularly, to filter
> the extra info fields.  Another interesting filter
> could be: threads stopped in "foo_regex" function,
> or address.
> 
> But still, the user will still have to manually pick
> the output of the previous command.  I think it'd even
> be better if the command had a switch that created a
> thread group (itset or thread set, whatever) from the threads
> that matched.  Only problem is we don't have thread
> sets support, yet.

I'm fine with a regex, but I don't particularly want to implement
thread sets just now.  Perhaps a future enhancement?  ;-)

Re: [rfc] 'thread tid' command

[Eli Zaretskii]

> Date: Fri, 11 Feb 2011 16:32:54 -0800
> From: Michael Snyder <msnyder@vmware.com>
> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> Pedro Alves wrote:
> > On Friday 11 February 2011 22:12:39, Michael Snyder wrote:
> >> This is purposefully rough, 'cause I hope for discussion.
> >>
> >> This is a new command to help manage large thread lists.
> >> I started with the idea "I want to find out which thread
> >> has target id 12345", then extended it to also handle the
> >> new concept of thread names (which thread has name 'foo'),
> >> and extra info as well (which thread has extra info that
> >> includes the string "xyz").
> >>
> >> The syntax (I'm open to renaming etc.):
> >>
> >>    thread tid [NAME | TARGET_ID | EXTRA_INFO]
> > 
> > Shouldn't this be under "info" or "show"?
> 
> Suits me, but
> 1) I'd prefer it wasn't "show", because there is no "set".
> 2) Info what?  tid?  thread-id?

  thread show [NAME | TARGET_ID | EXTRA_INFO]
  thread info [NAME | TARGET_ID | EXTRA_INFO]

Re: [rfc] 'thread tid' command

[Michael Snyder]

Eli Zaretskii wrote:
>> Date: Fri, 11 Feb 2011 16:32:54 -0800
>> From: Michael Snyder <msnyder@vmware.com>
>> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> Pedro Alves wrote:
>>> On Friday 11 February 2011 22:12:39, Michael Snyder wrote:
>>>> This is purposefully rough, 'cause I hope for discussion.
>>>>
>>>> This is a new command to help manage large thread lists.
>>>> I started with the idea "I want to find out which thread
>>>> has target id 12345", then extended it to also handle the
>>>> new concept of thread names (which thread has name 'foo'),
>>>> and extra info as well (which thread has extra info that
>>>> includes the string "xyz").
>>>>
>>>> The syntax (I'm open to renaming etc.):
>>>>
>>>>    thread tid [NAME | TARGET_ID | EXTRA_INFO]
>>> Shouldn't this be under "info" or "show"?
>> Suits me, but
>> 1) I'd prefer it wasn't "show", because there is no "set".
>> 2) Info what?  tid?  thread-id?
> 
>   thread show [NAME | TARGET_ID | EXTRA_INFO]
>   thread info [NAME | TARGET_ID | EXTRA_INFO]

How about "thread find"?

Re: [rfc] 'thread tid' command

[Michael Snyder]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Michael Snyder wrote:
> Eli Zaretskii wrote:
>>> Date: Fri, 11 Feb 2011 16:32:54 -0800
>>> From: Michael Snyder <msnyder@vmware.com>
>>> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>>
>>> Pedro Alves wrote:
>>>> On Friday 11 February 2011 22:12:39, Michael Snyder wrote:
>>>>> This is purposefully rough, 'cause I hope for discussion.
>>>>>
>>>>> This is a new command to help manage large thread lists.
>>>>> I started with the idea "I want to find out which thread
>>>>> has target id 12345", then extended it to also handle the
>>>>> new concept of thread names (which thread has name 'foo'),
>>>>> and extra info as well (which thread has extra info that
>>>>> includes the string "xyz").
>>>>>
>>>>> The syntax (I'm open to renaming etc.):
>>>>>
>>>>>    thread tid [NAME | TARGET_ID | EXTRA_INFO]
>>>> Shouldn't this be under "info" or "show"?
>>> Suits me, but
>>> 1) I'd prefer it wasn't "show", because there is no "set".
>>> 2) Info what?  tid?  thread-id?
>>   thread show [NAME | TARGET_ID | EXTRA_INFO]
>>   thread info [NAME | TARGET_ID | EXTRA_INFO]
> 
> How about "thread find"?

Here's a new diff combining both patches (since they sort of relate),
and implementing some of your suggestions.

  * info thread can now take a list of thread ids (closer to a thread set)
  * thread find (so called) can now take a regular expression.

Tom, since you implemented the thread name, I'd like to know if this
scheme fits in with what you had in mind.


[-- Attachment #2: tid.txt --]
[-- Type: text/plain, Size: 4474 bytes --]

2011-02-10  Michael Snyder  <msnyder@msnyder-server.eng.vmware.com>

	* thread.c (info_threads_command): Process arg as thread id,
	or list of thread ids.
	(thread_find_command): New command.
	(_initialize_thread): Document argument for info threads.
	Document 'thread find' command.

Index: thread.c
===================================================================
RCS file: /cvs/src/src/gdb/thread.c,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 thread.c
--- thread.c	19 Jan 2011 17:21:36 -0000	1.131
+++ thread.c	12 Feb 2011 23:53:18 -0000
@@ -43,6 +43,7 @@
 #include "observer.h"
 #include "annotate.h"
 #include "cli/cli-decode.h"
+#include "gdb_regex.h"
 
 /* Definition of struct thread_info exported to gdbthread.h.  */
 
@@ -957,15 +958,35 @@ No selected thread.  See `help thread'.\
 
 /* Print information about currently known threads 
 
- * Note: this has the drawback that it _really_ switches
- *       threads, which frees the frame cache.  A no-side
- *       effects info-threads command would be nicer.
- */
+   Optional ARG is a thread id, or list of thread ids.
+
+   Note: this has the drawback that it _really_ switches
+         threads, which frees the frame cache.  A no-side
+         effects info-threads command would be nicer.  */
 
 static void
 info_threads_command (char *arg, int from_tty)
 {
-  print_thread_info (uiout, -1, -1);
+  int tid = -1;
+
+  if (arg == NULL || *arg == '\0')
+    {
+      print_thread_info (uiout, -1, -1);
+      return;
+    }
+
+  while (arg != NULL && *arg != '\0')
+    {
+      int tmp_tid
+	= (int) parse_and_eval_long (scan_expression_with_cleanup (&arg,
+								   NULL));
+
+      if (tmp_tid != 0)
+	{
+	  tid = tmp_tid;
+	  print_thread_info (uiout, tid, -1);
+	}
+    }
 }
 
 /* Switch from one thread to another.  */
@@ -1313,6 +1334,56 @@ thread_name_command (char *arg, int from
   info->name = arg ? xstrdup (arg) : NULL;
 }
 
+/* Find thread ids with a name, target pid, or extra info matching ARG.  */
+
+static void
+thread_find_command (char *arg, int from_tty)
+{
+  struct thread_info *tp;
+  char *tmp;
+  unsigned long match = 0;
+
+  if (arg == NULL || *arg == '\0')
+    error (_("Command requires an argument."));
+
+  tmp = re_comp (arg);
+  if (tmp != 0)
+    error (_("Invalid regexp (%s): %s"), tmp, arg);
+
+  update_thread_list ();
+  for (tp = thread_list; tp; tp = tp->next)
+    {
+      if (tp->name != NULL && re_exec (tp->name))
+	{
+	  printf_filtered ("Thread %d has name '%s'\n", tp->num, tp->name);
+	  match++;
+	}
+
+      tmp = target_thread_name (tp);
+      if (tmp != NULL && re_exec (tmp))
+	{
+	  printf_filtered ("Thread %d has target name '%s'\n", tp->num, tmp);
+	  match++;
+	}
+
+      tmp = target_pid_to_str (tp->ptid);
+      if (tmp != NULL && re_exec (tmp))
+	{
+	  printf_filtered ("Thread %d has target id '%s'\n", tp->num, tmp);
+	  match++;
+	}
+
+      tmp = target_extra_thread_info (tp);
+      if (tmp != NULL && re_exec (tmp))
+	{
+	  printf_filtered ("Thread %d has extra info '%s'\n", tp->num, tmp);
+	  match++;
+	}
+    }
+  if (!match)
+    printf_filtered ("No threads match '%s'\n", arg);
+}
+
 /* Print notices when new threads are attached and detached.  */
 int print_thread_events = 1;
 static void
@@ -1403,8 +1474,10 @@ _initialize_thread (void)
 {
   static struct cmd_list_element *thread_apply_list = NULL;
 
-  add_info ("threads", info_threads_command,
-	    _("IDs of currently known threads."));
+  add_info ("threads", info_threads_command, _("\
+Usage: info threads [ID [ID]...].  Display currently known threads.\n\
+If ID is given, display only that thread or those threads;\
+otherwise, all threads are displayed."));
 
   add_prefix_cmd ("thread", class_run, thread_command, _("\
 Use this command to switch between threads.\n\
@@ -1418,11 +1491,15 @@ The new thread ID must be currently know
   add_cmd ("all", class_run, thread_apply_all_command,
 	   _("Apply a command to all threads."), &thread_apply_list);
 
-  add_cmd ("name", class_run, thread_name_command,
+  add_cmd ("name", no_class, thread_name_command,
 	   _("Set the current thread's name.\n\
 Usage: thread name [NAME]\n\
 If NAME is not given, then any existing name is removed."), &thread_cmd_list);
 
+  add_cmd ("find", no_class, thread_find_command, _("\
+Find thread ids with a name, target pid, or extra info matching REGEXP."),
+	   &thread_cmd_list);
+
   if (!xdb_commands)
     add_com_alias ("t", "thread", class_run, 1);
 

Re: [rfc] 'thread tid' command

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 11 Feb 2011 23:56:22 +0000
> Cc: Michael Snyder <msnyder@vmware.com>
> 
> > The syntax (I'm open to renaming etc.):
> > 
> >    thread tid [NAME | TARGET_ID | EXTRA_INFO]
> 
> Shouldn't this be under "info" or "show"?

Exactly my thoughts.  With a preference to "show".  (Don't worry about
"set", it will come soon enough ;-)