Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 337897

Summary:	[multi-process] The debug view is not properly updated when using multiple processes in all-stop mode
Product:	[Tools] CDT	Reporter:	Marc Khouzam <marc.khouzam>
Component:	cdt-debug-dsf-gdb	Assignee:	Project Inbox <cdt-debug-dsf-gdb-inbox>
Status:	NEW ---	QA Contact:	Jonah Graham <jonah>
Severity:	normal
Priority:	P3	CC:	cdtdoug, dalexiev, pawel.1.piech
Version:	8.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Marc Khouzam

2011-02-22 15:42:52 EST

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.

Comment 1 Marc Khouzam

2011-04-20 15:15:01 EDT

*** Bug 343449 has been marked as a duplicate of this bug. ***

Comment 2 Marc Khouzam

2011-04-20 15:39:06 EDT

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.

Comment 3 Marc Khouzam

2011-05-04 16:20:12 EDT

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.