This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Does multi-exec make sense without target-async?


> -----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.

Thanks!
Looks like I want that option 'on', to give some kind of value
to all-stop mode.  I'll give it a go.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]