Re: do_captured_thread_select

[Eirik Fuller <eirik at netapp dot com>]

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).

Thanks,
Eirik