From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7413 invoked by alias); 26 Apr 2008 16:34:22 -0000 Received: (qmail 7403 invoked by uid 22791); 26 Apr 2008 16:34:21 -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; Sat, 26 Apr 2008 16:34:04 +0000 Received: (qmail 6045 invoked from network); 26 Apr 2008 16:34:02 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Apr 2008 16:34:02 -0000 From: Vladimir Prus To: "Doug Evans" Subject: Re: MI non-stop interface details Date: Sat, 26 Apr 2008 19:49:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sourceware.org, "Pawel Piech" , "Marc Khouzam" References: <200804261939.37635.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804262034.00245.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-04/txt/msg00212.txt.bz2 On Saturday 26 April 2008 20:21:38 Doug Evans wrote: > On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus > wrote: > > At the same time, a suggestion was made to stop GDB to switch the (user-visible) > > current thread. This will have two advantages: > > > > - CLI users won't see the thread switches > > IOW GDB won't switch the current thread on the user, right? [just > want to understand what you're saying, not to suggest a preference, > per se] Yes. GDB will switch its internal "current thread" when processing event, but it will switch it back to whatever user has last set before processing next user command. > > 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. > > Scheduler-locking has two modes, "on" and "step". In case 1 above, > resuming just a single thread should already work if scheduler-locking > == "on" (IIUC). Yes. The question is -- does scheduler locking "off" make any kind of sense in non-stop mode. If not, we should not support it. > Having said that, specifying the request in a > parameter to -exec-* is probably a better way to go. > > IWBN if there was a way to have selective control of which threads run > (e.g. threads 3,5,7 stay stopped when execution resumes). > [controlling this in a parameter to -exec-*, as opposed to global > state, won't necessarily scale though] There is none, at the moment. I believe Nick has proposed some ways how this can be done, but there was not a demand for that yet. Maybe they will, when folks start using non-stop mode. > > > 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. > > 5. Introduce new command -query-feature (?) [assuming it's not there > already, I don't know] That will report if a feature is enabled or not? We don't have it (just like we don't have -enable-feature yet). I'm thinking, though, that for all features we'd document if it's enabled by default, or not, so this command might not be a big use. - Volodya