From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18251 invoked by alias); 27 Apr 2008 19:17:36 -0000 Received: (qmail 18241 invoked by uid 22791); 27 Apr 2008 19:17:35 -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; Sun, 27 Apr 2008 19:17:07 +0000 Received: (qmail 25139 invoked from network); 27 Apr 2008 19:17:04 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Apr 2008 19:17:04 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: MI non-stop interface details Date: Mon, 28 Apr 2008 16:21:00 -0000 User-Agent: KMail/1.9.9 Cc: Vladimir Prus , Pawel Piech , Marc Khouzam References: <200804261939.37635.vladimir@codesourcery.com> In-Reply-To: <200804261939.37635.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804272017.02620.pedro@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/msg00232.txt.bz2 A Saturday 26 April 2008 16:39:36, Vladimir Prus wrote: > [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 If we get rid of the auto thread switching, then GDB's current thread will always be the thread the frontend considers current too, because it was the frontend that made it the current thread. What is this "keeping track" you mention that would be needed for frontends not using --thread? Also, does --thread switch the current thread permanently as if -thread-select was used, or does it only change it for the processing of the command? That is, should GDB revert to the selected thread after processing an -exec-* --thread command? > - 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). > Not immediatelly. The *stopped notification will once per thread that reports a stop. The frontend would use it to update its internal state representing the thread (change the thread icon to a "-like paused icon for instance). The frontend would send -thread-select when the user activelly clicks on another thread icon (or equivalent action). It doesn't seem much different from switching the internal-to-the-frontend notion of current thread, from which the --thread=$id parameter is built. > 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. > Can we make -exec-continue/-exec-step/-exec-next consistent, by making the case of not passing a --thread parameter semantics match? Given the same arguments, if one resumes just one thread, the others should too, IMHO. If we choose to always ignore the scheduler-locking setting in non-stop mode, by making them operate on the current thread only, we can still honour '-exec-continue --thread="all"', or '-exec-step --all'. If people find it desirable, we can make "scheduler-locking off" with no --thread specified mean resume all threads. That I tend to agree is wrong in non-stop mode. I'd rather have two buttons on the IDE -- "resume" and "resume all", (or two keyboard shortcuts, etc.) then to export the sheduler-locking modes to the user interface. -- Pedro Alves