From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15532 invoked by alias); 14 Oct 2004 19:34:53 -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 15514 invoked from network); 14 Oct 2004 19:34:52 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 14 Oct 2004 19:34:52 -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 PAA05890 for ; Thu, 14 Oct 2004 15:29:00 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id PAA25250 for gdb@sources.redhat.com; Thu, 14 Oct 2004 15:34:51 -0400 Message-Id: <200410141934.PAA25250@smtp.ott.qnx.com> Subject: Re: MI thread commands To: cagney@gnu.org (Andrew Cagney) Date: Fri, 15 Oct 2004 12:50:00 -0000 From: "Alain Magloire" Cc: Cenedese@indel.ch (Fabian Cenedese), gdb@sources.redhat.com In-Reply-To: <416ECD13.8010001@gnu.org> from "Andrew Cagney" at Oct 14, 2004 03:01:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00319.txt.bz2 > > > 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.