This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]