From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 827 invoked by alias); 18 Oct 2004 17:32:11 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 804 invoked from network); 18 Oct 2004 17:32:08 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 18 Oct 2004 17:32:08 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id NAA23092 for ; Mon, 18 Oct 2004 13:25:50 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id NAA10471 for gdb@sources.redhat.com; Mon, 18 Oct 2004 13:32:07 -0400 Message-Id: <200410181732.NAA10471@smtp.ott.qnx.com> Subject: Re: MI thread commands To: jingham@apple.com (Jim Ingham) Date: Mon, 18 Oct 2004 21:05:00 -0000 From: "Alain Magloire" Cc: gdb@sources.redhat.com In-Reply-To: from "Jim Ingham" at Oct 15, 2004 10:55:52 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00346.txt.bz2 > > One thought here is that getting all this info for all threads is > currently expensive in gdb. You need to be careful about anything you > have to do each time the debugger steps, since people really notice > slowdowns in stepping performance. Unless you are displaying all this > info for every thread in the program, you might not want to fetch it. > Agreed. On some architecture like SH4(MIPS) it is a killer. Doing "info threads" was equivalent of walking the stackframes. Kris W. did something for me, for the QNX/Neutrino a special commands that return the list of tids. > Xcode just uses -thread-list-ids (which you might want to enhance to > add the "extra" bit since that would be useful to display in a "thread > list or popup" UI element. At the beginning, I though "-thread-list-ids" was a ligther version of "info threads" but I had problems with the command (beside the crashing), it did not show newly created threads. A GNAT PR was create for this. > We only get more info about a thread if we > actually have to display it's stack. For that reason, we have never > felt the need to implement thread-list-all-threads... > Yes, but we wanted to go further meaning showing when threads are created/destroyed even when the inferior is running, I have such code but ... it is terrible 8-) based on the "[System ..]" console output tag. Andrew C. pointed me in the right direction with the oberser.c code and libthread_db.so, but I lack time to look at this option seriously. > Also, I am sure you know this, but remember also that the active thread > is not necessarily the thread that you stopped at. The use can change > the thread (they can even do it in the console...) so gdb needs to > issue and the UI needs to pick up thread changed notifications. > Agreed. We are changing our things work with the IDE interface, so now if you want to do some actions, say evaluating an expression, the IDE must provide a context to evaluate (stackframe/thread) : // save current context ... -thread-select 2 -stack-select-frame 4 -data-evaluate-expresion "foobar" ... // restore context It is a little heavy, but seems to work ok. So we make sure that we do things in the right context. > Jim > > On Oct 15, 2004, at 8:40 AM, gdb-digest-help@sources.redhat.com wrote: > > > > > > >> > >>> Hi > >>> > >>> I didn't get a reply on this one so I thought I try again. > >>> > >>> > >>>>> What was the intention behind -thread-info? It's not explained in > >>>>> the > >>>>> manual and also not implemented (so much to "Read the source, > >>>>> Luke"). > >>>>> Should this bring the info that is available with "info threads" > >>>>> but for only > >>>>> one thread? Is there another possibility to get e.g. the thread > >>>>> name? > >>>>> > >>>>> I made my try with the -thread-list-all-threads command, but I'm > >>>>> not > >>>>> sure about the output format as it's nowhere described (Hey Bob, > >>>>> thanks > >>>>> for your rules :) Is this sensible? Or is it one level too much > >>>>> (the > >>>>> "threads=" level)? > >>>>> > >>>>> ^done,threads=[thread={id="12",pid="945832",extra=" Name: > >>>>> UserTaskName, State: 0 > >>>>> 002, Priority: > >>>>> 0007",frame={func="CTaskTemplateClass::Action",args=[{name="this" > >>>>> ,value="0xe6ea8"}],file="N:/Temp/ToThrow/psoism/applicat/src/ > >>>>> CTaskTemplateClass. > >>>>> cpp",line="454"}},thread={id="11",pid="956152",extra=" Name: > >>>>> IMP_MAS, State: 000 > >>>>> 9, Priority: > >>>>> 0000",frame={func="CINOSTask::MainLoop",args= > >>>>> [{name="this",value="0 > >>>>> xe96f8"}],file="N:/Temp/ToThrow/psoism/os/inos/Src/ > >>>>> Inos.cpp",line="856"}}..(snipped)..] > >>> > >>> > >>> Another problem I have is the active thread. If the info thread > >>> command is issued > >>> on the CLI gdb will indicate the selected thread with a '*' in front > >>> of it. Obviously > >>> that's not possible with the mi. How can this information be > >>> returned? Is there > >>> a way to add it to the -thread-list-all-threads, e.g. with a new > >>> field "active" only > >>> present in the active thread? Or should it be omitted in this > >>> command and put > >>> into a new/other mi command? e.g. the above mentioned -thread-info? > >> > >> Does a GUI, where all threads are displayed equal, have an "active" > >> thread? I guess you're looking to identify the thread at the head of > >> the list of threads that had a reason to stop - breakpoint, signal, > >> ... > >> > >> If MI clients think it's useful, it can be added. > >> > > > > When the inferior become suspended, in the response usually there is a > > thread-id > > for example: > > *stopped,reason="breakpoint-hit",thread-id=".." > > > > So the GUI will know the active thread. > > I've seen, however times where the thread-id was not in for some > > reason. > > In this case, for backward compatibility reason, we fallback to use > > "info threads" > > I believe there was a PR on this on GNATS. So far the latest gdbs > > seem to come back > > with a thread-id that make this PR less of a priority. > > > > > > > -- au revoir, alain ---- Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!