From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23877 invoked by alias); 2 May 2008 18:19:53 -0000 Received: (qmail 23857 invoked by uid 22791); 2 May 2008 18:19:52 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 May 2008 18:19:34 +0000 Received: (qmail 9586 invoked from network); 2 May 2008 18:19:31 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 May 2008 18:19:31 -0000 From: Vladimir Prus To: Pawel Piech Subject: Re: MI non-stop interface details Date: Fri, 02 May 2008 18:19:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Marc Khouzam , Pedro Alves , gdb@sourceware.org References: <6D19CA8D71C89C43A057926FE0D4ADAA042910AB@ecamlmw720.eamcs.ericsson.se> <200805022135.39862.vladimir@codesourcery.com> <481B5672.8080707@windriver.com> In-Reply-To: <481B5672.8080707@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805022219.32558.vladimir@codesourcery.com> 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/msg00029.txt.bz2 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? Frontend knows it already, no? - Volodya