From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6874 invoked by alias); 27 Sep 2006 14:18:32 -0000 Received: (qmail 6863 invoked by uid 22791); 27 Sep 2006 14:18:32 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Sep 2006 14:18:28 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-02.spheriq.net with ESMTP id k8REINpD008934 for ; Wed, 27 Sep 2006 14:18:23 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-03.spheriq.net with ESMTP id k8REIM9v031194 for ; Wed, 27 Sep 2006 14:18:23 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id k8REIKnP004325 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 27 Sep 2006 14:18:21 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C78FADA44; Wed, 27 Sep 2006 14:18:14 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7D73747523; Wed, 27 Sep 2006 14:18:14 +0000 (GMT) Received: from st.com (crx1177.cro.st.com [164.129.47.77]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CIN84852 (AUTH "denis pilat"); Wed, 27 Sep 2006 16:18:13 +0200 (CEST) Message-ID: <451A8825.5080906@st.com> Date: Wed, 27 Sep 2006 14:18:00 -0000 From: Denis PILAT User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 MIME-Version: 1.0 To: Alain Magloire Cc: Daniel Jacobowitz , nickrob@snap.net.nz, gdb@sourceware.org Subject: Re: info thread References: <3518719F06577C4F85DA618E3C37AB9106B12B6C@nimbus.ott.qnx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00162.txt.bz2 Alain Magloire wrote: > >>I think you're thinking of -thread-list-ids. Ah, this is mi/674. >>It's also mi/1040. Both of which suggest *stopped :-) >> >>We could add the thread to -thread-list-ids, too. >> >>Something to keep in mind: the thread "extra info" is expensive to >>collect on some platforms, e.g. requires asking the remote stub for >>details on each individual thread. >> >> > >Noted, but some platforms put some extra stuff in the output of "info >threads" like thread names, states, mutexes etc ... this information is then >retrieve by the IDE and shownn to the user. > Yes but to display this "extra stuffs" they have to customize their Eclipse (or any UI) to implement a parser for that. I think it will be more generic and cost less (in term of execution time) if "extra information" could be accessible thru an other mi command than -thread-list-ids. Generic part of the UI then calls -thread-list-ids Targets that want to display more information then just call a more complete command like -thread-list-all-threads or -thread-info on each thread. What I propose is the following: -thread-list-ids : INPUT: none OUTPUT: o list of IDs o Current thread could be the first (or last) item of the list, or warned by an asterisk -thread-list-all-threads INPUT: none OUTPUT: o like -thread-list-ids o plus the list of "extra information" per thread -thread-info INPUT: thread ID as an optional parameter, if not given the following concerns current thread OUTPUT: o thread ID (could be used to determine which is the current thread if not given in parameter) o extra information o stack frame Apart from the debate let me give you some measurements I did on a 100 threads program that runs on a board, debugged thru jtag. Figures for the "info thread" CLI command only: 70 % of the time is spent in getting the stack frame for all threads 1% on the "extra info" 29% on other stuff out of the loop that collect thread above information. Stack frame is the one that takes the most since it requires to switch the current thread and print the stack. Switching takes 60% of that time. Moreover extra information are reduced for our target. Please note that the total time is 7.2 seconds for this example !