do_captured_thread_select

do_captured_thread_select

[Eirik Fuller]

This patch allows gdb's thread command to be used in macros.  I've been
using it since mid November with no problems (and I apologize for the
delay in submitting it).

--- gdb/thread.c-	Wed Feb  2 20:14:36 2000
+++ gdb/thread.c	Thu Nov 16 20:31:42 2000
@@ -663,7 +670,7 @@
   int num;
   struct thread_info *tp;
 
-  num = atoi ((char *)tidstr);
+  num = value_as_long(parse_and_eval(tidstr));
 
   tp = find_thread_id (num);

Re: do_captured_thread_select

[Michael Snyder]

Eirik Fuller wrote:
> 
> This patch allows gdb's thread command to be used in macros.  I've been
> using it since mid November with no problems (and I apologize for the
> delay in submitting it).
> 
> --- gdb/thread.c-       Wed Feb  2 20:14:36 2000
> +++ gdb/thread.c        Thu Nov 16 20:31:42 2000
> @@ -663,7 +670,7 @@
>    int num;
>    struct thread_info *tp;
> 
> -  num = atoi ((char *)tidstr);
> +  num = value_as_long(parse_and_eval(tidstr));
> 
>    tp = find_thread_id (num);

Can you explain the significance of change?  Sorry if I'm being slow, 
but I don't see it.  What's the problem that you're fixing?

Also (not to be pedantic), we generally appreciate a ChangeLog entry
to accompany a patch.

Thanks, 
Michael Snyder

Re: do_captured_thread_select

[Michael Snyder]

Eirik Fuller wrote:
> 
> Sorry about the omitted ChangeLog entry in my previous message; here it is:
> 
>         * thread.c (do_captured_thread_select): Allow the argument to the
>         thread command to be an expression rather than a literal integer.
> 
> The patch makes gdb's thread command more useful in macros because thread
> specifiers can be computed on the fly.  For example, if a variable value in
> one thread specifies which thread was scheduled next, a gdb macro can trace
> the sequence of context switches.  Without the patch, the same thing can be
> done manually, but there's no way to wrap a loop around it.
> 
> In an offline discussion, the idea of making a similar change to the
> "thread apply" command was mentioned.  My patch doesn't do that, nor is
> it clear how (or whether) that should be done.  The worst complication
> is the ambiguity with respect to where the thread list ends and the
> command to be applied begins.  In the present code, the command begins
> with the first isalpha character after the thread list (which has a
> curious effect in a "thread apply" command with a gdb convenience
> variable).  Splitting on white space won't work because the command to
> be applied can have parameters.  Any character which is legal in the
> expression used to specify the thread list would presumably be unsuitable
> as a delimiter between the thread list and the command.
> 
> If there's a consensus that it would be useful to change the "thread apply"
> command to accept expressions in the thread list, and a workable idea of
> how to accomplish that without disrupting the present behavior, I'm willing
> to work on a patch.  In the meantime, I think accepting the simple patch
> is a good idea (it has no harmful effect on existing behavior, since any
> useful thread specifier will work with or without the patch).

OK, I haven't seen any other discussion, so I'll accept this patch.
Thank you Eirik