From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16218 invoked by alias); 20 Apr 2011 19:34:11 -0000 Received: (qmail 16208 invoked by uid 22791); 20 Apr 2011 19:34:10 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Apr 2011 19:33:57 +0000 Received: (qmail 24662 invoked from network); 20 Apr 2011 19:33:56 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Apr 2011 19:33:56 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Does multi-exec make sense without target-async? Date: Wed, 20 Apr 2011 19:34:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Marc Khouzam References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104202033.55140.pedro@codesourcery.com> 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: 2011-04/txt/msg00125.txt.bz2 On Wednesday 20 April 2011 19:35:26, Marc Khouzam wrote: > There is no point in running multi-exec without > target-async on, right? > > I mean, if I have two inferiors and I run one, > there is no way for me to tell GDB to also > run the second one? To do that, I have to > interrupt the first to get the prompt. > I originally thought of using 'continue -a' > to resume all inferiors, but the -a flag > is only for non-stop it seems. Yeah, GDB's internal all-stop model is not a good fit for multi-process. You either resume just all threads of a process, or all threads of all processes. It's controlled by this setting in all-stop mode: (gdb) help set schedule-multiple Set mode for resuming threads of all processes. When on, execution commands (such as 'continue' or 'next') resume all threads of all processes. When off (which is the default), execution commands only resume the threads of the current process. The set of threads that are resumed is further refined by the scheduler-locking mode (see help set scheduler-locking). Note, the setting applies to _all_ execution commands, like scheduler-locking. -- Pedro Alves