Re: do_captured_thread_select

[Michael Snyder <msnyder@cygnus.com>]

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