From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31192 invoked by alias); 28 Apr 2008 17:55:32 -0000 Received: (qmail 31181 invoked by uid 22791); 28 Apr 2008 17:55:31 -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; Mon, 28 Apr 2008 17:52:41 +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 m3SHqEU4003823 for ; Mon, 28 Apr 2008 10:52:14 -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); Mon, 28 Apr 2008 10:52:14 -0700 Received: from [147.11.233.126] ([147.11.233.126]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 10:52:14 -0700 Message-ID: <48160ECD.6020502@windriver.com> Date: Tue, 29 Apr 2008 03:14:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: MI non-stop interface details References: <200804261939.37635.vladimir@codesourcery.com> In-Reply-To: <200804261939.37635.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-04/txt/msg00242.txt.bz2 Vladimir, Thank you for the update and thank you for incorporating our feedback in your proposal. Having continued support for thread-select will make for a much smoother transition to this version of protocol. I only have a couple of comments below: Vladimir Prus wrote: > There are a couple of open questions. > > 1. Presently, -exec-continue resumes all threads, and the current thread > has no effect. I think it's desirable to be able to resume a single thread, > and for that, we actually need the --thread option for -exec-continue, to > mean that a single thread must be resumed. > 2. Presently, -exec-step also resumes all threads. There's an option, > "scheduler-locking" that can be used for cause -exec-step to resume only > the current thread. It seems to be, that for non-stop mode, resuming all > threads is a wrong thing to do, therefore -exec-step, when in non-stop > mode, will resume only the thread been stepped. This will be the same > no matter if the thread is specified implicitly or explicitly. > I agree with Pedro Alves that having the behavior for -exec-* be consistent would be very helpful. I would also suggest '-exec-continue --thread="all" '. Now if we'd be able use '-thread-select all', that would be even better... though I suspect you'll see lots of implementation issues with that. In either non-stop or all-stop mode, I expected to see extensions to the *stopped and *running events, which would indicate to the client whether one or all threads were resumed. If you want to be very forward looking you could use: *stopped,thread-id="2",thread-ids=[2, 3, 5],container-ids="[all]"... where : thread-id - Indicates the the thread that triggered the event, which is usually the thread that should receive the focus in the UI. thread-ids - List of all threads that were suspended, threads that are part of the container that stopped would be omitted. container-ids - list of containers (cores/processes/etc) that suspended. Until multi-process support is implemented, "all" would be the only possible value. Empty if only the thread suspended. > Inferior function calls > ----------------------- > > We already have the *stopped async event, and I have a patch to introduce the > *running async event. Those are not emitted when doing inferiour function calls, > since doing so may cause a frontend to infinitely refresh its state. I propose > the following mechanism to enable those notifications for frontends that > are sufficiently robust: > > 1. Declare that MI might have some features that are not enabled by default. > 2. Introduce new command -enable-feature, which takes a name of feature and enables > it. > 3. Make up a name of a feature, say inferior_call_notifications, and add that > feature to the output of -list-features. > 4. Make '-enable-feature inferior_call_notification' enable *running and *stopped > for inferiour function calls. > > Any comments? > This is a good compromise, would there be a special "reason" value, such as "evaluate"? Thanks, Pawel