This is the mail archive of the
mailing list for the GDB project.
- To: Eirik Fuller <eirik at netapp dot com>
- Subject: Re: do_captured_thread_select
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Tue, 17 Apr 2001 11:58:34 -0700
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Red Hat
- References: <39C17C60.3125D2C0@netapp.com> <39C18CBC.1BC1F728@netapp.com> <39D17683.FB3CA962@netapp.com> <3A113B77.B50A60D7@cygnus.com> <3A11D01C.7F0ADFCC@netapp.com> <3A11FA7A.CCC941C3@cygnus.com> <3A12022E.D96AB1EA@netapp.com> <3A15C2E7.6EC92753@netapp.com> <3AD17CE3.AA280B97@netapp.com> <3AD1FD8A.B2B197AB@cygnus.com> <3AD245A5.1BEA8615@netapp.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