From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23171 invoked by alias); 24 Nov 2008 03:09:13 -0000 Received: (qmail 23093 invoked by uid 22791); 24 Nov 2008 03:09:11 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Nov 2008 03:08:34 +0000 Received: (qmail 23727 invoked from network); 24 Nov 2008 03:08:24 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Nov 2008 03:08:24 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Add optional argument to "info threads" command Date: Mon, 24 Nov 2008 16:33:00 -0000 User-Agent: KMail/1.9.10 Cc: Michael Snyder References: <4928BC24.5020600@vmware.com> In-Reply-To: <4928BC24.5020600@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811240308.49485.pedro@codesourcery.com> 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/msg00632.txt.bz2 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. -- Pedro Alves