From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28475 invoked by alias); 29 Nov 2007 17:51:17 -0000 Received: (qmail 28460 invoked by uid 22791); 29 Nov 2007 17:51:15 -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; Thu, 29 Nov 2007 17:51:11 +0000 Received: (qmail 29881 invoked from network); 29 Nov 2007 17:51:09 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Nov 2007 17:51:09 -0000 From: Vladimir Prus To: Pawel Piech Subject: Re: Non-stop multi-threaded debugging Date: Thu, 29 Nov 2007 17:51:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb@sourceware.org References: <474CFA34.1030309@windriver.com> <200711291946.25035.vladimir@codesourcery.com> <474EF892.3030400@windriver.com> In-Reply-To: <474EF892.3030400@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711292051.01519.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: 2007-11/txt/msg00278.txt.bz2 On Thursday 29 November 2007 20:36:18 Pawel Piech wrote: > Vladimir Prus wrote: > > On Thursday 29 November 2007 19:39:18 Pawel Piech wrote: > > > > > >> I don't believe that I suggested adding any new command. > >> Instead, I suggested only changing the behavior of > >> some of the existing commands to use the currently selected thread. > >> It was Jim's proposal that included adding new commands. > >> My point was that instead of adding new commands it would be cleaner > >> to extend the functionality of -thread-select in order to select > >> a process context, i.e. a context that includes all threads. > >> This way existing commands, which currently can only operate > >> on a global context, could now operate on a process or a thread context. > >> > > > > Ok, we have those choices: > > > > 1. Make -exec-continue work on all threads, until -thread-select is used. > > 2. Make -exec-continue work on one thread, and add another command > > to operate on all threads. > > 3. Make -exec-continue still operate on all threads, unless > > and explicit option to make it operate on a thread is given. > > > > You've indicated that (1) and (3) are about the same in complexity for you -- > > am I right? > This is correct. > > I personally prefer (3), since it does not implicitly changes > > the meaning of existing commands. > > > > Surely, non-stop mode does require some changes in frontend, but the > > fewer changes are, the better, IMO. > > > > - Volodya > > > > In that case I'll try to convince you otherwise :-) > > -exec-continue is not the only command that would need to be modified. > -exec-interrupt, would all need to take the -p parameter, and in order > to implement multi-process debugging, many of the commands that > currently operate on a global context (too many to try to list) would > all require an additional parameter to specify which process they are to > act on. There seems to be a well established paradigm in the MI (and > CLI) protocol, where special commands: -thread-select and > -stack-frame-select change the state of the protocol so that commands > following these operate on the context selected by these commands. There are different opinions about those commands ;-) For example, I believe that stateless protocol would be much easier. > My > main point is to extend the functionality of these state-changing > commands in order to add the ability to select an active context, and to > select a context which will allow commands to operate on all the threads > of a process. > > IMO, the question of whether -exec-continue takes a -p argument is a > rather minor one. But for sake of consistency with other -exec-* > commands I think it would be a mistake to add this parameter. That's > because the stepping commands already do operate on the currently > selected thread. While all the threads are resumed when stepping, > execution does not stop until the next line of code is reached by the > thread that was selected. With non-stop debugging, stepping commands > will continue to operate on the selected thread with the difference that > other suspended threads will remain suspended. Interesting. Presently, in CLI gdb set 'scheduler mode' that controls if step resumes all thread, or not. MI does not have a counterpart of that. Maybe, we should start by changing -exec-step to accept a thread parameter, too, which would mean "step only this thread, keep others suspended". Then, -exec-continue taking thread parameter will be quite consistent with -exec-step. I would say such change to -exec-step will be valuable in itself. - Volodya