From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9790 invoked by alias); 24 Nov 2008 19:06:41 -0000 Received: (qmail 9692 invoked by uid 22791); 24 Nov 2008 19:06:40 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Nov 2008 19:06:04 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id C2A721305E; Mon, 24 Nov 2008 11:05:54 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost2.vmware.com (Postfix) with ESMTP id A7BCD8E5E0; Mon, 24 Nov 2008 11:05:54 -0800 (PST) Message-ID: <492AFAE8.4040405@vmware.com> Date: Mon, 24 Nov 2008 21:22:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: Re: [RFA] Add optional argument to "info threads" command References: <4928BC24.5020600@vmware.com> <200811240308.49485.pedro@codesourcery.com> In-Reply-To: <200811240308.49485.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00656.txt.bz2 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.