From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28483 invoked by alias); 5 Jun 2008 21:23:58 -0000 Received: (qmail 28474 invoked by uid 22791); 5 Jun 2008 21:23:58 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 21:23:28 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m55LNRNX016093 for ; Thu, 5 Jun 2008 14:23:27 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 14:23:26 -0700 Received: from [147.11.233.79] ([147.11.233.79]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 14:23:27 -0700 Message-ID: <4848594E.5010403@windriver.com> Date: Thu, 05 Jun 2008 21:23:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: non-stop and current thread exiting References: <6D19CA8D71C89C43A057926FE0D4ADAA0429117A@ecamlmw720.eamcs.ericsson.se> <200806051727.19098.vladimir@codesourcery.com> In-Reply-To: <200806051727.19098.vladimir@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00036.txt.bz2 Vladimir Prus wrote: > ... > >>> You are right that some frontend changes will be required -- but they >>> are required anyway to show the "running" state of the thread, so >>> seems the extra change to show "exited" state does not add much >>> complexity. >>> >> If the output of thread-list-ids is simply augmented with (exited), >> you are right that it would be an easy change for a frontend. >> > > Actually, I plan that in the output of -thread-info, each thread will have a field > 'state', that can be either 'stopped' or 'running' or 'exited'. So, a frontend > not wishing to specially display exited threads will ignore threads with > state=exited. > > (Incidentally, we might want to introduce more fine-grained values of state, like > 'stepping'). > That's great! It would be even better if the state change events included this fine-grained information as well (e.g. *running,reason="step"). Cheers, Pawel