From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32247 invoked by alias); 2 May 2008 18:36:30 -0000 Received: (qmail 32239 invoked by uid 22791); 2 May 2008 18:36:29 -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 18:36:08 +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 m42IZhuM029086; Fri, 2 May 2008 11:35:43 -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 11:35:42 -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 11:35:42 -0700 Message-ID: <481B5EF9.10000@windriver.com> Date: Fri, 02 May 2008 18:36: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> <200805022135.39862.vladimir@codesourcery.com> <481B5672.8080707@windriver.com> <200805022219.32558.vladimir@codesourcery.com> In-Reply-To: <200805022219.32558.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/msg00030.txt.bz2 Vladimir Prus wrote: > On Friday 02 May 2008 21:59:14 Pawel Piech wrote: > >> 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. >> > > And what the triggering thread would report in that case? The thread where > the step command was emitted? Right. > Frontend knows it already, no? > > - Volodya > Right, it typically does... unless the command was issued through the CLI console, in which case the UI has to do some work to get it. But as long as GDB has the information, it's simpler and more reliable to get it from the event. -Pawel