From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19577 invoked by alias); 29 Apr 2008 17:05:26 -0000 Received: (qmail 19563 invoked by uid 22791); 29 Apr 2008 17:05:23 -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; Tue, 29 Apr 2008 17:05:06 +0000 Received: (qmail 10758 invoked from network); 29 Apr 2008 17:05:04 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Apr 2008 17:05:04 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: MI non-stop interface details Date: Tue, 29 Apr 2008 19:21: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> <200804272017.02620.pedro@codesourcery.com> In-Reply-To: <200804272017.02620.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804292104.58288.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/msg00250.txt.bz2 On Sunday 27 April 2008 23:17:02 Pedro Alves wrote: > 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? Suppose that for whatever reason, frontend would like to do anything in a thread that is not explicitly selected by a user. Then, frontend gets to switch to that thread, do something, and switch back, and should take care that no other operation is done while we've temporary switched threads. > 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? Right now, --thread switches the thread permanently. Which is quite fine if frontend always adds --thread. > > - 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). Of course, a frontend that, in response to *stopped, will do nothing but marking a thread as stopped, will be fairly unpopular :-) Usually, you want to show the variables at the stop point, so you'd switch to the stop thread. > 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. Too late. -exec-continue resumes everything. -exec-step, from user standpoint, resumes one -- most users don't even know that step can resume all threads. > 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. I guess we can redefine the behaviour of -exec-continue in non-stop, or in MI3, but I worry that two different behaviours will make life too hard for frontends (and for us) - Volodya