From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14908 invoked by alias); 10 Apr 2007 15:14:02 -0000 Received: (qmail 14893 invoked by uid 22791); 10 Apr 2007 15:13:59 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Apr 2007 16:13:51 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id C533F4B267; Tue, 10 Apr 2007 10:13:49 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 995164B262; Tue, 10 Apr 2007 10:13:49 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HbI2R-00034Y-57; Tue, 10 Apr 2007 11:13:43 -0400 Date: Tue, 10 Apr 2007 15:14:00 -0000 From: Daniel Jacobowitz To: Denis PILAT Cc: Nick Roberts , gdb-patches Subject: Re: [RFC] -thread-info new command Message-ID: <20070410151342.GA10890@caradoc.them.org> Mail-Followup-To: Denis PILAT , Nick Roberts , gdb-patches References: <45FE9E6A.3030906@st.com> <17919.15500.439138.600411@kahikatea.snap.net.nz> <17919.20575.286260.761826@kahikatea.snap.net.nz> <20070320031409.GA7336@caradoc.them.org> <17919.21588.93918.661753@kahikatea.snap.net.nz> <17921.40699.742164.983281@kahikatea.snap.net.nz> <20070327195414.GN28164@caradoc.them.org> <17929.36288.344474.485310@farnswood.snap.net.nz> <4613B7E5.6080309@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4613B7E5.6080309@st.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-04/txt/msg00086.txt.bz2 On Wed, Apr 04, 2007 at 04:36:21PM +0200, Denis PILAT wrote: > Is there anything new about that ? > Should I re-propose a patch for -thread-info ? Yes, please. Although, I think that a manual patch is a more useful way to start the discussion for a new MI command than a code patch. You said in your original posting that Eclipse uses info threads but only collects the thread ID and extra info from it; so I think the two useful commands for Eclipse are "-thread-info" which returns the extra info, and something which returns all the IDs and extra info. Then you can use one if you know only a few threads are visible, and the other if you want to eagerly cache all the thread info. The other two maybe useful models for an IDE are "all threads, with stack but without extra info" and "all threads with both stack and extra info". That might depend on a lot of things. If the IDE knows in advance that the thread extra info never changes, it can avoid requesting it. Nick and Vladimir were talking about -var-list a month or so ago. Maybe we should have something similar here - WDYT? -thread-list [--extra] [--stack] Or maybe we should always provide the extra info, and have a way to tell GDB that it never changes, so it can avoid the expensive queries to the target. -- Daniel Jacobowitz CodeSourcery