From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Eirik Fuller Cc: gdb-patches@sourceware.cygnus.com Subject: Re: do_captured_thread_select Date: Tue, 17 Apr 2001 11:58:00 -0000 Message-id: <3ADC925A.1FCF3B97@cygnus.com> 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> X-SW-Source: 2001-04/msg00171.html 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