[RFA] Add optional argument to "info threads" command

[Michael Snyder]

Pedro Alves wrote:
> On Sunday 23 November 2008 02:12:52, Michael Snyder wrote:
>> I've long been frustrated because I could not ask for
>> info about just one or more threads.
>>
>> This patch makes use of command parsing code in breakpoint.c
>> to give "info threads" the same optional arguments as "info
>> breakpoints", ie. a list of one or more threads of interest,
>> or a range of threads (eg. "5-9").
>>
>>
>> OK?
> 
> I'd like to point out that if you're debugging a multi-threaded
> application with lots of threads (the case where you'd want to use
> the range of threads feature), your implementation will, for
> each id in the specified range:
> 
>  1. call prune_threads.
> 
>     This is a bunch of T (thread alive) packets in the remote target,
>     one for each thread in the thread list -- not for each in
>     range, really *for all* threads.
> 
>  2. call target_find_new_threads.
> 
>     A bunch of qfThreadInfo packets.  One for *each remote thread*, not
>     just the ones specified in the range.
> 
>  3. do a make_cleanup_restore_current_thread and restore
>     the selected thread and frame once for each thread in the
>     range.  This triggers about the double amount of registers
>     and memory reads than necessary.
> 
>  4. also, there's a chance you'll hit the same warning in
>     restore_selected_frame once for each id in the range.
> 
> If you consider remote targets, and thinking that this new
> feature would be most useful if you have many threads,
> points 1-3 above can be heavy against not so fast links.  I
> suggest abstracting out the bits in print_thread_info that do the
> actual printing from the bits that prune dead threads, find
> new threads, and restore the original selected frame.

Well, all your observations are correct -- but the same thing
also happens if you merely switch the thread of focus using the
"thread" command.

I do think that prune-threads and target_find_new_threads
are being called too aggressively from somewhere, but it
isn't directly from info_threads_command.

I think this is a separate, pre-existing problem that this patch
helps to reveal.