From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21577 invoked by alias); 29 Nov 2007 17:36:53 -0000 Received: (qmail 21568 invoked by uid 22791); 29 Nov 2007 17:36:52 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 Nov 2007 17:36:40 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lATHaJHY014180; Thu, 29 Nov 2007 09:36:19 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 09:36:19 -0800 Received: from [147.11.233.83] ([147.11.233.83]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 09:36:19 -0800 Message-ID: <474EF892.3030400@windriver.com> Date: Thu, 29 Nov 2007 17:36:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Vladimir Prus CC: gdb@sourceware.org Subject: Re: Non-stop multi-threaded debugging References: <474CFA34.1030309@windriver.com> <474EEB36.1040203@windriver.com> <200711291946.25035.vladimir@codesourcery.com> In-Reply-To: <200711291946.25035.vladimir@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-11/txt/msg00277.txt.bz2 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. 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. It seems logical to me that -exec-continue and -exec-interrupt should operate in the same way. In the degenerate case where the target is not capable non-stop multi-threaded debugging, conceptually these commands can still be thought of as operating on the selected thread, with the side effect that when one thread is resumed/suspended, all threads are resumed/suspended as well. Cheers, Pawel