From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16949 invoked by alias); 29 Nov 2007 16:42:57 -0000 Received: (qmail 16940 invoked by uid 22791); 29 Nov 2007 16:42:56 -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 16:42:49 +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 lATGgmoq001722 for ; Thu, 29 Nov 2007 08:42:48 -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 08:42:48 -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 08:42:48 -0800 Message-ID: <474EEC07.9040303@windriver.com> Date: Thu, 29 Nov 2007 16:42:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Non-stop multi-threaded debugging References: <474CFA34.1030309@windriver.com> <18254.7923.167270.745538@kahikatea.snap.net.nz> <474E58EF.2060601@windriver.com> In-Reply-To: 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/msg00275.txt.bz2 Vladimir Prus wrote: > Pawel Piech wrote: > > >> Nick Roberts wrote: >> >>> > ... A -thread-select on an >>> > ID of a process followed by an -exec-continue would resume an entire >>> > process, while a -thread-select of a thread's ID followed by a >>> > continue >>> > would resume only that thread. This could also be applied to all >>> > other commands that need to operate on a process, such as >>> > -thread-list-ids, -break-insert, etc. >>> >>> This would change the current behaviour of these commands. If a new >>> command is undesirable then perhaps optional parameters could be used: >>> >>> -exec-continue [ -p THREAD-ID/PROCESS-ID ] >>> -exec-interrupt [ -p THREAD-ID/PROCESS-ID ] >>> >>> It appears that -break-insert already has such an option for threads. >>> >>> >>> >> From Eclipse's point of view it actually doesn't make much difference >> whether -thread-select or -p option is used to specify the thread. >> >> That said, I would argue that adding the non-stop debugging feature >> changes the behavior of the entire system, so it could be expected that >> some commands will behave somewhat differently as they relate to this >> new feature. Actually, with non-stop debugging feature turned off, and >> without attaching to multiple processes, these commands would still >> behave exactly as they do now. >> > > Given the choice between: > > 1. Changing the behaviour of the existing command, and adding new one > that behaves like existing one, and > > 2. Adding new command > > I think adding new command (or option to existing command), is a smaller change. > So yes, -exec-continue -t might be a better choice. > > - Volodya > 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. Cheers, Pawel