From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3039 invoked by alias); 26 Apr 2008 15:40:04 -0000 Received: (qmail 3028 invoked by uid 22791); 26 Apr 2008 15:40:03 -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 15:39:40 +0000 Received: (qmail 4974 invoked from network); 26 Apr 2008 15:39:38 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Apr 2008 15:39:38 -0000 From: Vladimir Prus To: gdb@sourceware.org Subject: MI non-stop interface details Date: Sat, 26 Apr 2008 18:09:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Pawel Piech , Marc Khouzam MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804261939.37635.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/msg00210.txt.bz2 [Marc, Pawel, I CC you since you were involved in the original discussions about MI interface for non-stop mode]. Some time ago I've posted a spec for MI interface in non-stop mode. The discussion (and subsequent implementation) revealed a couple of details that I'd like to finally settle. Thread specification -------------------- With non-stop mode, we have a possible race condition due to GDB notion of current thread. GDB both uses the current thread to decide on which thread the operation like 'step' should work, and it switches the current thread when a stop event in a thread is detected. As the result, if a frontend emits a command assuming that that current thread is N, and stop even is detected before that command is executed, it will execute in the wrong thread. The current non-stop patches introduce a --thread option to pretty much every MI command, that make MI operate on the specified thread. I think this is the best interface, and will document it as such in the MI docs. 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 - Some existing frontends are more easily adjusted to this interface. In particular, Eclipse DSF-GDB does not have a central place where the --thread option can be conveniently added. Pedro Alves has written a patch that disables the current thread switch, so this approach is in fact possible. I think this leaves us with the following scheme: - In non-stop mode, the current thread is not automatically switched on stops - All MI commands will get the --thread option, as that allows the frontend not to bother with keeping track of the current thread. This option will be recommended in the manual - Frontend authors that know what they are doing can ignore the --thread option. (They will have to explicitly emit -thread-select, presumably immediately after seeing the *stopped notification). 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. 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? - Volodya