Community
Participate
Working Groups
As for multi-threaded programs, multi-process programs in GDB can run in all-stop or non-stop mode. When in all-stop mode, when a process resumes or suspends, all other processes do the same. Currently, our VMNodes don't handle this case properly but instead only update the process that triggered the resume/suspend event. This is because the existing multi-process support of CDT was done for non-stop, where events of one process don't affect another process.
*** Bug 343449 has been marked as a duplicate of this bug. ***
It looks like to get a multi-process all-stop that has any kind of value, we need to enable the schedule-multiple option. From http://sourceware.org/ml/gdb/2011-04/msg00125.html: -----Original Message----- From: Pedro Alves [mailto:pedro@codesourcery.com] Sent: Wednesday, April 20, 2011 3:34 PM To: gdb@sourceware.org Cc: Marc Khouzam Subject: Re: Does multi-exec make sense without target-async? 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.
Another thing to keep in mind was reported in Bug 341406 where connecting/starting a second process will not be possible while the target is running, when in all-stop. The solution I have in mind is to: forcibly interrupt the target (like we do for a detach/terminate/breakpoint) before doing the attach. The problem here is that an attach is actually two operations: first listing the processes, and then doing the attach. To avoid interrupting the target for a long time, while the user selects a second process, we should probably interrupt once to list the processes and then resume; once the user makes her choice, we should then interrupt again, attach and resume again.
