From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6145 invoked by alias); 30 May 2009 13:10:34 -0000 Received: (qmail 6137 invoked by uid 22791); 30 May 2009 13:10:33 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout5.012.net.il (HELO mtaout5.012.net.il) (84.95.2.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 May 2009 13:10:26 +0000 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KKG00200KG1QG00@i_mtaout5.012.net.il> for gdb-patches@sourceware.org; Sat, 30 May 2009 16:10:24 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.115.215]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KKG0058ZKLBER40@i_mtaout5.012.net.il>; Sat, 30 May 2009 16:10:24 +0300 (IDT) Date: Sat, 30 May 2009 13:10:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] In-reply-to: <200905301151.52892.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, marc.khouzam@ericsson.com Reply-to: Eli Zaretskii Message-id: <83fxem4tz4.fsf@gnu.org> References: <200905301151.52892.pedro@codesourcery.com> 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-05/txt/msg00649.txt.bz2 > From: Pedro Alves > Date: Sat, 30 May 2009 11:51:52 +0100 > Cc: Marc Khouzam > > Currently, with the generic framework, if GDB is attached to > multiple processes, issuing a "continue", "next", etc., makes GDB > resume all threads of all processes. But, with the multi-forks > framework, GDB only debugs one of the forks at a given time, while > leaving the others stopped. E.g., > > (gdb) set detach-on-fork off > (gdb) catch fork > Catchpoint 1 (fork) > (gdb) r > Starting program: /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/foll-fork > > Catchpoint 1 (forked process 23902), 0x00007ffff789ac4b in fork () from /lib/libc.so.6 > (gdb) > > A 'continue' command here, will only resume the parent process, and leave > the child process stopped. > This means that moving multi-forks into multi-inferior framework changes > its behaviour. If we make execution commands resume only > threads of the current inferior, then we're changing the current > default for targets making use of the current > multi-inferior framework... So, we've got a conflict, and something's got > to give. :-/ Both variants are reasonable and which one is right depends on > what you're debugging. Can you give at least 2 different use-cases, each one favoring one of the possible behaviors? I'm not sure I understand the nature of the conflict. A few comments about the patch for the manual: > +@cindex resume multiple processes This index entry is too general. I suggest something more specific to the aspects you are describing. > +By default, @value{GDBN} allows only threads of the current inferior > +to run in response to execution commands such as @code{continue}. We don't introduce the notion of "execution commands" until the node that's after this one. So if you want to use it here, I would suggest to add the definition of this term in the parent node ("Thread Stops"), and while at that, give a more-or-less comprehensive list of the commands that are considered to be "execution commands". > +@cindex resume multiple processes This second instance of the same index item is redundant. > +Sets the mode for scheduling multiple processes. When set, all ^^^^ We use "Set", not "Sets", throughout the manual. Also, I suggest to mention threads: Set the mode for scheduling threads of multiple processes. On second thought, "scheduling" is not the best word here, as GDB is not a scheduler. How about "continuing the execution"? > +threads of all processes are allowed to run. When not set (which is > +the default), only the threads of the current process are schedulable. I think we say "when OFF" and "when ON", rather than "when set" and "when not set". > +@item show schedule-multiple > +Display the current mode for scheduling multiple processes. Same comment about "threads" and "scheduling". > +The final set of threads that are allowed to run by execution commands > +is defined by the union of the restrictions implied by both the > +@code{schedule-multiple} and @code{scheduler-locking} modes. E.g., if > +the @code{schedule-multiple} mode is set to @code{on}, but the > +scheduler locking mode is also set to @code{on}, then only the current > +thread is made schedulable. It might be easier and simpler to tell that scheduler-locking takes precedence. > +When set, all threads of all processes are affected by execution\n\ > +commands (such as e.g., 'continue'). When not set (which is the\n\ You do not need both "such as" and "e.g.", one or the other is enough. Also, the same comments as above about "ON/OFF" vs "set/not set" apply here. We will also need an entry in NEWS for this new option. Thanks.