From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7709 invoked by alias); 9 Jun 2009 04:01:40 -0000 Received: (qmail 7432 invoked by uid 22791); 9 Jun 2009 04:01:39 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Jun 2009 04:01:28 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MDsWc-0006so-BA; Tue, 09 Jun 2009 00:01:26 -0400 From: Eli Zaretskii To: Pedro Alves CC: gdb-patches@sourceware.org In-reply-to: <200906081259.54338.pedro@codesourcery.com> (message from Pedro Alves on Mon, 8 Jun 2009 12:59:53 +0100) Subject: Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] Reply-to: Eli Zaretskii References: <200905301151.52892.pedro@codesourcery.com> <200905301701.53207.pedro@codesourcery.com> <83d49q4is6.fsf@gnu.org> <200906081259.54338.pedro@codesourcery.com> Message-Id: Date: Tue, 09 Jun 2009 04:01:00 -0000 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00206.txt.bz2 > From: Pedro Alves > Date: Mon, 8 Jun 2009 12:59:53 +0100 > > On Saturday 30 May 2009 18:12:09, Eli Zaretskii wrote: > > > Thanks, the new patch for the manual and the NEWS entry are fine with > > me, but please consider the two remaining issues mentioned above. > > Certainly! I'd really like you to be happy with this and here's my > next attempt at that. I've given a short example of why you'd want > either behaviour; used "resuming the execution", and switched to > mentioning the scheduler-locking precedence instead. Thanks. > +@cindex resume threads of multiple processes simultaneously > +By default, @value{GDBN} allows only threads of the current inferior > +to run in response to execution commands such as @code{continue}, > +@code{next} or @code{step}. E.g., if @value{GDBN} is attached to two > +inferiors, each with two threads, the @code{continue} command resumes > +only the two threads of the current inferior. This is useful for > +example when debugging a program that forks, and you want to hold the > +fork parent stopped (so that for instance it doesn't run to exit), > +while debugging the child. In other ocasions, you are not interested > +in inspecting the current state of none of the processes @value{GDBN} > +is attached to, and you want to resume them all until any reports a > +breakpoint hit. You can modify @value{GDBN}'s default behavior by > +instead allowing all threads of all inferiors to run with the > +@w{@code{set schedule-multiple}} command. This is indeed what I had in mind, but the wording needs some improvement. I suggest this variant: By default, when you issue one of the execution commands such as @code{continue}, @code{next} or @code{step}, @value{GDBN} allows only threads of the current inferior to run. For example, if @value{GDBN} is attached to two inferiors, each with two threads, the @code{continue} command resumes only the two threads of the current inferior. This is useful, for example, when you debug a program that forks and you want to hold the parent stopped (so that, for instance, it doesn't run to exit), while you debug the child. In other situations, you may not be interested in inspecting the current state of any of the processes @value{GDBN} is attached to, and you may want to resume them all until some breakpoint is hit. In the latter case, you can instruct @value{GDBN} to allow all threads of all the inferiors to run with the @w{@code{set schedule-multiple}} command. OK? The rest of documentation-related hunks are fine with me. Thanks.