From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1900 invoked by alias); 26 Apr 2008 16:22:03 -0000 Received: (qmail 1892 invoked by uid 22791); 26 Apr 2008 16:22:02 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Apr 2008 16:21:45 +0000 Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id m3QGLeEZ032163 for ; Sat, 26 Apr 2008 17:21:40 +0100 Received: from wa-out-1112.google.com (wahv33.prod.google.com [10.114.248.33]) by spaceape23.eur.corp.google.com with ESMTP id m3QGLdVE013256 for ; Sat, 26 Apr 2008 17:21:39 +0100 Received: by wa-out-1112.google.com with SMTP id v33so5831795wah.2 for ; Sat, 26 Apr 2008 09:21:38 -0700 (PDT) Received: by 10.114.210.2 with SMTP id i2mr4543824wag.198.1209226898677; Sat, 26 Apr 2008 09:21:38 -0700 (PDT) Received: by 10.115.107.18 with HTTP; Sat, 26 Apr 2008 09:21:38 -0700 (PDT) Message-ID: Date: Sat, 26 Apr 2008 18:16:00 -0000 From: "Doug Evans" To: "Vladimir Prus" Subject: Re: MI non-stop interface details Cc: gdb@sourceware.org, "Pawel Piech" , "Marc Khouzam" In-Reply-To: <200804261939.37635.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200804261939.37635.vladimir@codesourcery.com> 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/msg00211.txt.bz2 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] > 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). 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] > 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]