From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3587 invoked by alias); 2 May 2008 18:00:07 -0000 Received: (qmail 3565 invoked by uid 22791); 2 May 2008 18:00:06 -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; Fri, 02 May 2008 17:59:44 +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 m42HxKnB014181; Fri, 2 May 2008 10:59:20 -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); Fri, 2 May 2008 10:59:20 -0700 Received: from [147.11.37.213] ([147.11.37.213]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 10:59:20 -0700 Message-ID: <481B5672.8080707@windriver.com> Date: Fri, 02 May 2008 18:00:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Vladimir Prus CC: Marc Khouzam , Pedro Alves , gdb@sourceware.org Subject: Re: MI non-stop interface details References: <6D19CA8D71C89C43A057926FE0D4ADAA042910AB@ecamlmw720.eamcs.ericsson.se> <200805022113.13214.vladimir@codesourcery.com> <481B4FDC.4010802@windriver.com> <200805022135.39862.vladimir@codesourcery.com> In-Reply-To: <200805022135.39862.vladimir@codesourcery.com> Content-Type: text/plain; charset=UTF-8; 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-05/txt/msg00028.txt.bz2 Vladimir Prus wrote: > On Friday 02 May 2008 21:31:08 Pawel Piech wrote: > > >> Right now, *stopped reports the thread which hit the breakpoint. In >> all-stop mode, all threads are stopped. In non-stop mode, only that thread >> is stopped. >> >> We surely can add an extra field to indicate which threads are actually stopped, >> if this makes life easier. >> >> Thank You :-) It would be more helpful if the thread-id field was >> left alone and always reported the triggering thread as it does now. >> It would be better (more consistent and logical) if the new field >> was used to indicate whether or not the whole container changed state. >> > > For avoidance of doubt, do you have any objections to *running using the "thread-id" > as the field name? Since this is new notification, there's no backward compatibility > issues, and there's no issue of which thread originally triggered anything. > > - Volodya > First of all, I think it's important to make the events in all-stop and non-stop mode to be consistent. Additionally, it is helpful if the fields, such as thread-id have consistent meaning even if they are used in different events. So for consistency sake it would be better to also use thread-id to indicate the triggering thread in the running event as well, and use a separate field to indicate whether the container changed state. BTW the triggering thread is needed in the running event, for example when stepping in the all-stop mode. -Pawel