From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10129 invoked by alias); 28 Sep 2006 14:35:43 -0000 Received: (qmail 9967 invoked by uid 22791); 28 Sep 2006 14:35:41 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 28 Sep 2006 14:35:33 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Sep 2006 10:35:30 -0400 Message-ID: <3518719F06577C4F85DA618E3C37AB9106B136FA@nimbus.ott.qnx.com> From: Alain Magloire To: Denis PILAT Cc: Daniel Jacobowitz , nickrob@snap.net.nz, gdb@sourceware.org Subject: RE: info thread Date: Thu, 28 Sep 2006 14:35:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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/msg00178.txt.bz2 > From: Denis PILAT [mailto:denis.pilat@st.com] > Sent: Wednesday, September 27, 2006 10:18 AM > To: Alain Magloire > Cc: Daniel Jacobowitz; nickrob@snap.net.nz; gdb@sourceware.org > Subject: Re: info thread > > > > 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. > > Agreed, if we the UI views are smart enough to tell which threads are visible to the users then the implementation can be lazy in getting the info. > 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 > > OK. And in term of format, are we talking tuple/list? There was some inconsistencies in the old MI versions. Also for extra information you are probably mean "optional extra information" will that be an opaque string or name=value pairs. > > 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 ! On some architecture "info threads" can make things extremely slow, since the IDE will have to poll at every step to discover created/destroyed threads. For the long run we should probably look at notifications.