From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26447 invoked by alias); 15 Oct 2004 17:55:46 -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 26438 invoked from network); 15 Oct 2004 17:55:44 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 15 Oct 2004 17:55:44 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i9FI0Fgt012263 for ; Fri, 15 Oct 2004 11:00:15 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Fri, 15 Oct 2004 10:55:42 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i9FHtekn002750 for ; Fri, 15 Oct 2004 10:55:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v677) In-Reply-To: <1097854821.16300.ezmlm@sources.redhat.com> References: <1097854821.16300.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI thread commands Date: Fri, 15 Oct 2004 18:50:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2004-10/txt/msg00331.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. 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. 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... 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. 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. > > >