* [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
@ 2009-05-30 10:51 Pedro Alves
2009-05-30 13:10 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Pedro Alves @ 2009-05-30 10:51 UTC (permalink / raw)
To: gdb-patches; +Cc: Marc Khouzam
Hi guys,
While moving the linux native multi-forks support ("info forks") into
the generic multi-inferior framework I've ran into a little snag.
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. I'm thinking that the multi-forks behaviour
should be the default, as it seems to be less surprising, and, it was
here before...
So, I've came up with this new command so that the user
can select the behaviour desired. This currently only affects
all-stop mode.
What do you think of this?
I'd prefer that GDB had notion of dynamic thread groups, a-la
totalview, but I think we're a bit far for that yet, and
it sounds like we'd still make use of something like this
to affect the defaults.
[Marc, you've guessed it, I'm CCing you because this may
affect your current eclipse all-stop multi-process support. If this
sticks, you'll just need to issue "set schedule-multiple on" once
to get the current behaviour.]
--
Pedro Alves
2009-05-30 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (All-Stop): Document new 'set schedule-multiple'
command.
2009-05-30 Pedro Alves <pedro@codesourcery.com>
* infrun.c (sched_multi): New global.
(resume): If sched_multi is set, resume only threads of the
current inferior.
(prepare_to_proceed): Don't switch over to wait_ptid if we're
resuming a different inferior, and sched_multi is off.
(show_schedule_multiple): New.
(_initialize_infrun): Register new "schedule-multiple" command.
* inferior.h (sched_multi): Declare.
---
gdb/doc/gdb.texinfo | 27 +++++++++++++++++++++
gdb/inferior.h | 2 +
gdb/infrun.c | 64 +++++++++++++++++++++++++++++++++++++++++++---------
3 files changed, 83 insertions(+), 10 deletions(-)
Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo 2009-05-30 10:28:15.000000000 +0100
+++ src/gdb/doc/gdb.texinfo 2009-05-30 11:36:02.000000000 +0100
@@ -4650,6 +4650,33 @@ the current thread away from the thread
Display the current scheduler locking mode.
@end table
+@cindex resume multiple processes
+By default, @value{GDBN} allows only threads of the current inferior
+to run in response to execution commands such as @code{continue}.
+E.g., if @value{GDBN} is attached to two inferiors, each with two
+threads, the @code{continue} command resumes only the two threads of
+the current inferior. You can modify @value{GDBN}'s default behavior
+by allowing all threads of all inferiors to be scheduled.
+
+@table @code
+@kindex set schedule-multiple
+@item set schedule-multiple
+@cindex resume multiple processes
+Sets the mode for scheduling multiple processes. When set, all
+threads of all processes are allowed to run. When not set (which is
+the default), only the threads of the current process are schedulable.
+
+@item show schedule-multiple
+Display the current mode for scheduling multiple processes.
+@end table
+
+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.
+
@node Non-Stop Mode
@subsection Non-Stop Mode
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c 2009-05-30 01:36:41.000000000 +0100
+++ src/gdb/infrun.c 2009-05-30 11:35:01.000000000 +0100
@@ -1091,6 +1091,11 @@ set_schedlock_func (char *args, int from
}
}
+/* True if execution commands resume all threads of all processes by
+ default; otherwise, resume only threads of the current inferior
+ process. */
+int sched_multi = 0;
+
/* Try to setup for software single stepping over the specified location.
Return 1 if target_resume() should use hardware single step.
@@ -1201,13 +1206,25 @@ a command like `return' or `jump' to con
{
ptid_t resume_ptid;
- resume_ptid = RESUME_ALL; /* Default */
-
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(singlestep_breakpoints_inserted_p && step));
+ /* Decide the set of threads to ask the target to resume. Start
+ by assuming everything will be resumed, than narrow the set
+ by applying increasingly restricting conditions. */
+
+ /* By default, resume all threads of all processes. */
+ resume_ptid = RESUME_ALL;
+
+ /* Maybe resume only all threads of the current process. */
+ if ((!sched_multi || step) && target_supports_multi_process ())
+ {
+ resume_ptid = pid_to_ptid (ptid_get_pid (inferior_ptid));
+ }
+
+ /* Maybe resume a single thread after all. */
if (singlestep_breakpoints_inserted_p
&& stepping_past_singlestep_breakpoint)
{
@@ -1224,9 +1241,8 @@ a command like `return' or `jump' to con
to support, and has no value. */
resume_ptid = inferior_ptid;
}
-
- if ((step || singlestep_breakpoints_inserted_p)
- && tp->trap_expected)
+ else if ((step || singlestep_breakpoints_inserted_p)
+ && tp->trap_expected)
{
/* We're allowing a thread to run past a breakpoint it has
hit, by single-stepping the thread with the breakpoint
@@ -1240,8 +1256,7 @@ a command like `return' or `jump' to con
breakpoint, not just the one at PC. */
resume_ptid = inferior_ptid;
}
-
- if (non_stop)
+ else if (non_stop)
{
/* With non-stop mode on, threads are always handled
individually. */
@@ -1394,11 +1409,19 @@ prepare_to_proceed (int step)
|| (scheduler_mode == schedlock_step
&& step));
+ /* Don't switch over to WAIT_PTID if scheduler locking is on. */
+ if (schedlock_enabled)
+ return 0;
+
+ /* Don't switch over if we're about to resume some other process
+ other than WAIT_PTID's, and schedule-multiple is off. */
+ if (!sched_multi
+ && ptid_get_pid (wait_ptid) != ptid_get_pid (inferior_ptid))
+ return 0;
+
/* Switched over from WAIT_PID. */
if (!ptid_equal (wait_ptid, minus_one_ptid)
- && !ptid_equal (inferior_ptid, wait_ptid)
- /* Don't single step WAIT_PID if scheduler locking is on. */
- && !schedlock_enabled)
+ && !ptid_equal (inferior_ptid, wait_ptid))
{
struct regcache *regcache = get_thread_regcache (wait_ptid);
@@ -5573,6 +5596,14 @@ show_non_stop (struct ui_file *file, int
value);
}
+static void
+show_schedule_multiple (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ fprintf_filtered (file,
+ _("Scheduling multiple processes simultaneously is %s.\n"),
+ value);
+}
void
_initialize_infrun (void)
@@ -5752,6 +5783,19 @@ step == scheduler locked during every si
show_scheduler_mode,
&setlist, &showlist);
+ add_setshow_boolean_cmd ("schedule-multiple", class_run, &sched_multi, _("\
+Set mode for scheduling multiple processes simultaneously."), _("\
+Show mode for scheduling multiple processes simultaneously."), _("\
+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\
+default), only the threads of the current process are made\n\
+schedulable. The set of threads that are resumed is further\n\
+refined by the scheduler-locking mode (see help set\n\
+scheduler-locking)."),
+ NULL,
+ show_schedule_multiple,
+ &setlist, &showlist);
+
add_setshow_boolean_cmd ("step-mode", class_run, &step_stop_if_no_debug, _("\
Set mode of the step operation."), _("\
Show mode of the step operation."), _("\
Index: src/gdb/inferior.h
===================================================================
--- src.orig/gdb/inferior.h 2009-05-30 01:36:12.000000000 +0100
+++ src/gdb/inferior.h 2009-05-30 01:37:18.000000000 +0100
@@ -135,6 +135,8 @@ extern void clear_proceed_status (void);
extern void proceed (CORE_ADDR, enum target_signal, int);
+extern int sched_multi;
+
/* When set, stop the 'step' command if we enter a function which has
no line number information. The normal behavior is that we step
over such function. */
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-30 10:51 [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] Pedro Alves
@ 2009-05-30 13:10 ` Eli Zaretskii
2009-05-30 16:01 ` Pedro Alves
2009-05-31 16:34 ` Doug Evans
2009-06-01 14:29 ` Marc Khouzam
2 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2009-05-30 13:10 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, marc.khouzam
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sat, 30 May 2009 11:51:52 +0100
> Cc: Marc Khouzam <marc.khouzam@ericsson.com>
>
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-30 13:10 ` Eli Zaretskii
@ 2009-05-30 16:01 ` Pedro Alves
2009-05-30 17:12 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Pedro Alves @ 2009-05-30 16:01 UTC (permalink / raw)
To: gdb-patches, Eli Zaretskii; +Cc: marc.khouzam
On Saturday 30 May 2009 14:10:23, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Sat, 30 May 2009 11:51:52 +0100
> > Cc: Marc Khouzam <marc.khouzam@ericsson.com>
> >
> > 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.
As I've explained above. When debugging with a multi-process aware target,
and you're debugging multiple inferiors, "continue" resumes all threads
of all processes. When debugging multi-forks on linux native, and
you're attached to multiple forks, "continue" resumes all threads
of *the current process* only. The conflict is that both "multi-process"
implementations behave differently, and I'm getting rid of the multi-forks
support as-is. But, I'd like to keep the option of having its behaviour.
So, I'm adding the command so that the user can select what behaviour is
wanted, either resume all processes, or current process only. Use case
is "user wants to resume all processes" vs "user wants to resume only
the current process".
The multi-forks.exp test makes use of the "resume threads of the
current process only" variant. It breaks badly if I allow all
threads of all processes to be resumed. I've chosen the conservative
default of behaving like the multi-forks.exp test expects.
> 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.
Putting myself in a user's perspective, if I wanted to know how to
resume multiple process simultaneously, I'd go look for resume, multiple,
maybe I should add "simultaneously". Did you have something
completely different in mind?
> > +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".
I do mention "such as @code{continue}". I'm now including a couple more examples.
I can't see where "execution commands" are defined anywhere in other contexts
either, so this hasn't been a problem so far. I think that such a change
should be done independently of this one, perhaps then adding cross references
everywhere appropriate.
gdb.texinfo:to run in response to execution commands such as @code{continue}.
gdb.texinfo:The final set of threads that are allowed to run by execution commands
gdb.texinfo:execution commands such as @code{continue} and @code{step} apply by default
gdb.texinfo:In non-stop mode, all execution commands apply only to the current thread
gdb.texinfo:You can use @value{GDBN}'s background execution commands
gdb.texinfo:The MI execution commands (@pxref{GDB/MI Program Execution}) are
gdb.texinfo:Other execution commands do not currently support the @code{-a} option.
gdb.texinfo:@value{GDBN}'s execution commands have two variants: the normal
gdb.texinfo:background execution commands. You can use these commands to
gdb.texinfo:message if you attempt to use the background execution commands.
gdb.texinfo:just @code{c&}. The execution commands that accept background execution
gdb.texinfo:the restriction that you cannot issue another execution command until the
gdb.texinfo:@value{GDBN} will perform all execution commands in reverse, until the
gdb.texinfo:@value{GDBN} will perform all execution commands in the normal fashion.
gdb.texinfo:replay it later with both forward and reverse execution commands.
gdb.texinfo:associated with the stop message is the one for the execution command
gdb.texinfo:asynchronous just like other execution commands. That is, first the
>
> > +@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.
Ok.
>
> 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"?
as in:
Set the mode for continuing the execution of multiple processes.
? I think that "continuing" may trigger confusion by making it
look like only the "continue" command is affected. See new patch below.
>
> > +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".
Ah, I see that, in the manual. There are a few examples of boolean settings
in GDB's online help that use "When set", and I happened to copy from
one of those ("set step-mode", which is right below the new setting).
I've used ON/OFF everywhere now.
> > +@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.
It does not really take scrict precedence, due to the "step" scheduler-locking
variant. I think it would be odd because I'd have to explain that
modes other than "scheduler-locking off" takes some sort of precedence.
Here's the set of modes this allows.
- continue all threads of all processes
schedule-multiple on + scheduler-locking off
- continue all threads of the current process (default)
schedule-multiple off + scheduler-locking off
- continue all threads of all processes, unless step is issued,
in that case, step only the current thread.
schedule-multiple on + scheduler-locking step
- continue all threads of the current process, unless step is
issued, in that case, step only the current thread.
schedule-multiple off + scheduler-locking step
- step only the current thread.
schedule-multiple X + scheduler-locking on
IMO, these are intuitive given the nature and description
of both commands.
I thought of implementing this new feature new modes of
scheduler-locking instead, something like so:
set scheduler-locking off
(all threads of all processes can run)
set scheduler-locking all-not-current-process
(all threads of the current process can run, others remain locked)
set scheduler-locking all-not-current-process-step
(all threads not of the current process remain locked,
except when stepping, in which case, lock all except
the current thread)
set scheduler-locking step
(no thread is locked (all threads of all processes can run),
except when stepping, in that case, lock all except
the current thread)
set scheduler-locking on
(all threads but the current remain locked)
But I looked to me that this is harder to understand. The
nature of the "step" variant seems to want to be a different
setting from "resume all processes or just current process".
But I'm certainly open for discussion, hence the RFC.
It's certainly possible that experience shows that these modes
should be refined a bit differently. In the mean time, this allows
me to go on with adding support for linux multi-process/multi-exec.
>
> > +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.
Ok.
> Also, the same comments as above about "ON/OFF" vs "set/not set" apply
> here.
Ok.
> We will also need an entry in NEWS for this new option.
Yep. I was holding for the RFC to settle, but I've done
this now.
New patch below. Thanks.
--
Pedro Alves
2009-05-30 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (All-Stop): Document new 'set schedule-multiple'
command.
2009-05-30 Pedro Alves <pedro@codesourcery.com>
* infrun.c (sched_multi): New global.
(resume): If sched_multi is set, resume only threads of the
current inferior.
(prepare_to_proceed): Don't switch over to wait_ptid if we're
resuming a different inferior, and sched_multi is off.
(show_schedule_multiple): New.
(_initialize_infrun): Register new "set schedule-multiple" command.
* inferior.h (sched_multi): Declare.
* NEWS: Mention new "schedule-multiple" setting.
---
gdb/NEWS | 5 ++++
gdb/doc/gdb.texinfo | 30 ++++++++++++++++++++++++
gdb/inferior.h | 2 +
gdb/infrun.c | 63 +++++++++++++++++++++++++++++++++++++++++++---------
4 files changed, 90 insertions(+), 10 deletions(-)
Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo 2009-05-30 10:28:15.000000000 +0100
+++ src/gdb/doc/gdb.texinfo 2009-05-30 16:34:46.000000000 +0100
@@ -4650,6 +4650,36 @@ the current thread away from the thread
Display the current scheduler locking mode.
@end table
+@cindex resume threads of multiple processes simultaneously
+By default, @value{GDBN} allows only threads of the current inferior
+to run in response to execution commands such as @code{continue},
+@code{next} or @code{step}. E.g., if @value{GDBN} is attached to two
+inferiors, each with two threads, the @code{continue} command resumes
+only the two threads of the current inferior. You can modify
+@value{GDBN}'s default behavior by allowing all threads of all
+inferiors to run instead.
+
+@table @code
+@kindex set schedule-multiple
+@item set schedule-multiple
+Set the mode for allowing threads of multiple processes to be
+scheduled when an execution command is issued. When @code{on}, all
+threads of all processes are allowed to run. When @code{off}, only
+the threads of the current process are schedulable. The default is
+@code{off}.
+
+@item show schedule-multiple
+Display the current mode for allowing threads of multiple processes to
+run.
+@end table
+
+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.
+
@node Non-Stop Mode
@subsection Non-Stop Mode
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c 2009-05-30 01:36:41.000000000 +0100
+++ src/gdb/infrun.c 2009-05-30 16:19:21.000000000 +0100
@@ -1091,6 +1091,11 @@ set_schedlock_func (char *args, int from
}
}
+/* True if execution commands resume all threads of all processes by
+ default; otherwise, resume only threads of the current inferior
+ process. */
+int sched_multi = 0;
+
/* Try to setup for software single stepping over the specified location.
Return 1 if target_resume() should use hardware single step.
@@ -1201,13 +1206,25 @@ a command like `return' or `jump' to con
{
ptid_t resume_ptid;
- resume_ptid = RESUME_ALL; /* Default */
-
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(singlestep_breakpoints_inserted_p && step));
+ /* Decide the set of threads to ask the target to resume. Start
+ by assuming everything will be resumed, than narrow the set
+ by applying increasingly restricting conditions. */
+
+ /* By default, resume all threads of all processes. */
+ resume_ptid = RESUME_ALL;
+
+ /* Maybe resume only all threads of the current process. */
+ if (!sched_multi && target_supports_multi_process ())
+ {
+ resume_ptid = pid_to_ptid (ptid_get_pid (inferior_ptid));
+ }
+
+ /* Maybe resume a single thread after all. */
if (singlestep_breakpoints_inserted_p
&& stepping_past_singlestep_breakpoint)
{
@@ -1224,9 +1241,8 @@ a command like `return' or `jump' to con
to support, and has no value. */
resume_ptid = inferior_ptid;
}
-
- if ((step || singlestep_breakpoints_inserted_p)
- && tp->trap_expected)
+ else if ((step || singlestep_breakpoints_inserted_p)
+ && tp->trap_expected)
{
/* We're allowing a thread to run past a breakpoint it has
hit, by single-stepping the thread with the breakpoint
@@ -1240,8 +1256,7 @@ a command like `return' or `jump' to con
breakpoint, not just the one at PC. */
resume_ptid = inferior_ptid;
}
-
- if (non_stop)
+ else if (non_stop)
{
/* With non-stop mode on, threads are always handled
individually. */
@@ -1394,11 +1409,19 @@ prepare_to_proceed (int step)
|| (scheduler_mode == schedlock_step
&& step));
+ /* Don't switch over to WAIT_PTID if scheduler locking is on. */
+ if (schedlock_enabled)
+ return 0;
+
+ /* Don't switch over if we're about to resume some other process
+ other than WAIT_PTID's, and schedule-multiple is off. */
+ if (!sched_multi
+ && ptid_get_pid (wait_ptid) != ptid_get_pid (inferior_ptid))
+ return 0;
+
/* Switched over from WAIT_PID. */
if (!ptid_equal (wait_ptid, minus_one_ptid)
- && !ptid_equal (inferior_ptid, wait_ptid)
- /* Don't single step WAIT_PID if scheduler locking is on. */
- && !schedlock_enabled)
+ && !ptid_equal (inferior_ptid, wait_ptid))
{
struct regcache *regcache = get_thread_regcache (wait_ptid);
@@ -5573,6 +5596,14 @@ show_non_stop (struct ui_file *file, int
value);
}
+static void
+show_schedule_multiple (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ fprintf_filtered (file, _("\
+Allowing threads of multiple processes be scheduled simultaneously is %s.\n"),
+ value);
+}
void
_initialize_infrun (void)
@@ -5752,6 +5783,18 @@ step == scheduler locked during every si
show_scheduler_mode,
&setlist, &showlist);
+ add_setshow_boolean_cmd ("schedule-multiple", class_run, &sched_multi, _("\
+Set mode for allowing threads of multiple processes to be scheduled."), _("\
+Show mode for allowing threads of multiple processes to be scheduled."), _("\
+When on, execution commands (such as 'continue') resume all threads of\n\
+all processes. When off (which is the default), execution commands\n\
+only resume the threads of the current process. The set of threads\n\
+that are resumed is further refined by the scheduler-locking mode (see\n\
+help set scheduler-locking)."),
+ NULL,
+ show_schedule_multiple,
+ &setlist, &showlist);
+
add_setshow_boolean_cmd ("step-mode", class_run, &step_stop_if_no_debug, _("\
Set mode of the step operation."), _("\
Show mode of the step operation."), _("\
Index: src/gdb/inferior.h
===================================================================
--- src.orig/gdb/inferior.h 2009-05-30 01:36:12.000000000 +0100
+++ src/gdb/inferior.h 2009-05-30 12:49:53.000000000 +0100
@@ -135,6 +135,8 @@ extern void clear_proceed_status (void);
extern void proceed (CORE_ADDR, enum target_signal, int);
+extern int sched_multi;
+
/* When set, stop the 'step' command if we enter a function which has
no line number information. The normal behavior is that we step
over such function. */
Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS 2009-05-30 16:22:56.000000000 +0100
+++ src/gdb/NEWS 2009-05-30 16:35:58.000000000 +0100
@@ -305,6 +305,11 @@ show libthread-db-search-path
Control list of directories which GDB will search for appropriate
libthread_db.
+set schedule-multiple (on|off)
+show schedule-multiple
+ Allow GDB to resume all threads of all processes or only threads of
+ the current process.
+
* New native configurations
x86/x86_64 Darwin i[34567]86-*-darwin*
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-30 16:01 ` Pedro Alves
@ 2009-05-30 17:12 ` Eli Zaretskii
2009-06-08 11:59 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2009-05-30 17:12 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, marc.khouzam
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sat, 30 May 2009 17:01:52 +0100
> Cc: marc.khouzam@ericsson.com
>
> > 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.
>
> As I've explained above.
Well, thanks, but your original explanation was clear enough. What I
was asking for are use-cases where each of the two possible behaviors
would be preferable to the other.
> The conflict is that both "multi-process" implementations behave
> differently, and I'm getting rid of the multi-forks support as-is.
Sorry, I'm confused: if you are getting rid of multi-forks, won't the
conflict go away with it as well?
> Use case is "user wants to resume all processes" vs "user wants to
> resume only the current process".
Yes, but when would the latter be undesirable if the user uses
multi-forks? If using multi-forks means the user will always want to
resume only the current process, we don't need the new option.
> > > +@cindex resume multiple processes
> >
> > This index entry is too general. I suggest something more specific to
> > the aspects you are describing.
>
> Putting myself in a user's perspective, if I wanted to know how to
> resume multiple process simultaneously, I'd go look for resume, multiple,
> maybe I should add "simultaneously". Did you have something
> completely different in mind?
You are not describing how to resume multiple process simultaneously.
You are describing how to control whether all of them or only one will
be resumed.
Your new index entry is fine.
> > 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"?
>
> as in:
>
> Set the mode for continuing the execution of multiple processes.
>
> ? I think that "continuing" may trigger confusion by making it
> look like only the "continue" command is affected. See new patch below.
How about "resuming the execution", then?
> > > +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.
>
> It does not really take scrict precedence, due to the "step" scheduler-locking
> variant.
You could say that it takes precedence when set to ON.
Thanks, the new patch for the manual and the NEWS entry are fine with
me, but please consider the two remaining issues mentioned above.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-30 10:51 [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] Pedro Alves
2009-05-30 13:10 ` Eli Zaretskii
@ 2009-05-31 16:34 ` Doug Evans
2009-05-31 16:40 ` Doug Evans
2009-05-31 18:31 ` Tom Tromey
2009-06-01 14:29 ` Marc Khouzam
2 siblings, 2 replies; 16+ messages in thread
From: Doug Evans @ 2009-05-31 16:34 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Sat, May 30, 2009 at 3:51 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> 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.
Except in non-stop mode when "c -a" is required to continue all
threads, "c" by itself just continues the current thread (right?).
[And IWBN if there were a way to continue a subgroup of threads though
I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"? I
realize that's perhaps not ideal, but short of adding another command
it's the first thing that came to me. :-) And no claim is made that
this hasn't been discussed before ...]
I wonder what the normal usage pattern will be of multiprocess debugging.
An alternative to "set scheduler-multiple on|off" is to add another
flag to the various commands.
"scheduler-multiple" may be The Right Thing To Do, but adding more
global state that controls command behaviour gives me pause
("exec-direction" anyone?). Another way to add scheduler-locking
would have been to add options to "step", etc. "s -l" or some such
["l" for "locking" though "locking" out of place here, it's just an
example anyway]. It's easier to script:
# This isn't implementable today, it's just for illustration.
define lstep
set $save_scheduler_locking [get scheduler-locking]
try
step
finally
set scheduler-locking $save_scheduler_locking
end
end
versus
define lstep
step -l
end
I'd be curious to hear what others think.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-31 16:34 ` Doug Evans
@ 2009-05-31 16:40 ` Doug Evans
2009-05-31 18:31 ` Tom Tromey
1 sibling, 0 replies; 16+ messages in thread
From: Doug Evans @ 2009-05-31 16:40 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
Blech.
On Sun, May 31, 2009 at 9:33 AM, Doug Evans <dje@google.com> wrote:
> # This isn't implementable today, it's just for illustration.
> define lstep
> set $save_scheduler_locking [get scheduler-locking]
> try
+ set scheduler-locking-step
> step
> finally
> set scheduler-locking $save_scheduler_locking
> end
> end
>
> versus
>
> define lstep
> step -l
> end
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-31 16:34 ` Doug Evans
2009-05-31 16:40 ` Doug Evans
@ 2009-05-31 18:31 ` Tom Tromey
2009-05-31 18:38 ` Doug Evans
2009-05-31 22:06 ` Pedro Alves
1 sibling, 2 replies; 16+ messages in thread
From: Tom Tromey @ 2009-05-31 18:31 UTC (permalink / raw)
To: Doug Evans; +Cc: Pedro Alves, gdb-patches
>>>>> "Doug" == Doug Evans <dje@google.com> writes:
Doug> [And IWBN if there were a way to continue a subgroup of threads though
Doug> I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"? I
Doug> realize that's perhaps not ideal, but short of adding another command
Doug> it's the first thing that came to me. :-) And no claim is made that
Doug> this hasn't been discussed before ...]
Yeah, I think this is the "itset" idea that Stan mentioned and that
Pedro referred to (IIUC) as being totalview-like:
http://sourceware.org/ml/gdb/2008-08/msg00169.html
(The wiki should link to this note IMO... perhaps I will edit it in.)
Doug> I wonder what the normal usage pattern will be of multiprocess debugging.
Doug> An alternative to "set scheduler-multiple on|off" is to add another
Doug> flag to the various commands.
Doug> "scheduler-multiple" may be The Right Thing To Do, but adding more
Doug> global state that controls command behaviour gives me pause
Doug> ("exec-direction" anyone?).
I agree. Global settings seem particularly user-unfriendly when
debugging multiple inferiors. E.g., what if you want to reverse-debug
one inferior but none of the others? I suppose you can make the
settings per-inferior. But this also seems to have potential for a
lot of user confusion.
Doug> Another way to add scheduler-locking would have been to add
Doug> options to "step", etc. "s -l" or some such ["l" for "locking"
Doug> though "locking" out of place here, it's just an example
Doug> anyway].
Yeah.
Doug> # This isn't implementable today, it's just for illustration.
Doug> define lstep
[...]
You can implement this with Python today :-) ...
Doug> set $save_scheduler_locking [get scheduler-locking]
Here you use gdb.parameter.
Doug> try
Python's try/catch works with gdb exceptions.
Tom
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-31 18:31 ` Tom Tromey
@ 2009-05-31 18:38 ` Doug Evans
2009-05-31 22:06 ` Pedro Alves
1 sibling, 0 replies; 16+ messages in thread
From: Doug Evans @ 2009-05-31 18:38 UTC (permalink / raw)
To: tromey; +Cc: Pedro Alves, gdb-patches
On Sun, May 31, 2009 at 11:29 AM, Tom Tromey <tromey@redhat.com> wrote:
> Doug> # This isn't implementable today, it's just for illustration.
> Doug> define lstep
> [...]
>
> You can implement this with Python today :-) ...
>
> Doug> set $save_scheduler_locking [get scheduler-locking]
>
> Here you use gdb.parameter.
>
> Doug> try
>
> Python's try/catch works with gdb exceptions.
Thanks. I suspected as much, but it was secondary to my main point so
I didn't invest much time in it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-31 18:31 ` Tom Tromey
2009-05-31 18:38 ` Doug Evans
@ 2009-05-31 22:06 ` Pedro Alves
2009-06-01 15:55 ` Doug Evans
1 sibling, 1 reply; 16+ messages in thread
From: Pedro Alves @ 2009-05-31 22:06 UTC (permalink / raw)
To: tromey; +Cc: Doug Evans, gdb-patches
On Sunday 31 May 2009 19:29:19, Tom Tromey wrote:
> >>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> [And IWBN if there were a way to continue a subgroup of threads though
> Doug> I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"? I
> Doug> realize that's perhaps not ideal, but short of adding another command
> Doug> it's the first thing that came to me. :-) And no claim is made that
> Doug> this hasn't been discussed before ...]
>
> Yeah, I think this is the "itset" idea that Stan mentioned and that
> Pedro referred to (IIUC) as being totalview-like:
>
> http://sourceware.org/ml/gdb/2008-08/msg00169.html
Yes, sort of. itsets as stan described are just basically HPD's ptsets:
http://sourceware.org/frysk/documentation/hpd.pdf
In fact, a lot of what's described in Stan's spec is HPD influenced. Totalview
has similar concepts, and, it also has concept of something like dynamic
thread control groups. See:
http://www.totalviewtech.com/support/documentation/totalview/index.html
Using Threads Processes and Threads
Types of Threads
Organizing Chaos
Note that given that non-stop controls threads individually, these
groups *can be implemented on the frontend side*, so this isn't really
*the* high priority to me. Yes, I do think it is a nice feature to
have on the cli as well.
>
> (The wiki should link to this note IMO... perhaps I will edit it in.)
Sure, go ahead.
>
> Doug> I wonder what the normal usage pattern will be of multiprocess debugging.
>
> Doug> An alternative to "set scheduler-multiple on|off" is to add another
> Doug> flag to the various commands.
> Doug> "scheduler-multiple" may be The Right Thing To Do, but adding more
> Doug> global state that controls command behaviour gives me pause
> Doug> ("exec-direction" anyone?).
>
> I agree. Global settings seem particularly user-unfriendly when
> debugging multiple inferiors. E.g., what if you want to reverse-debug
> one inferior but none of the others? I suppose you can make the
> settings per-inferior. But this also seems to have potential for a
> lot of user confusion.
>
> Doug> Another way to add scheduler-locking would have been to add
> Doug> options to "step", etc. "s -l" or some such ["l" for "locking"
> Doug> though "locking" out of place here, it's just an example
> Doug> anyway].
>
> Yeah.
Re. 'c -t 1 2 3', and similars, you're skipping a lot of ground.
The current all-stop design is very limited run-control wise, and
doesn't allow all those sorts of things. E.g., the current target_resume
interface (and all the proceed/resume design) is limited in that you have to
tell the target what you want to resume in only a single call (think remote
protocol vCont --- as soon as you tell the target
to resume whatever, the target won't accept any other commands until something
stops). I've mentioned before that gdb's resume interface would probably
benefit from reusing gdb's gdbserver target_resume interface ideas. We'd
probably need to implement support for "held threads" as well, which by
itself is a good idea in the long run. This is all a non-short
amount of work.
Non-stop, however, avoids all these issues by working on top
of an asynchronous target interface. Unfortunatelly, I haven't
seen any effort in making all targets implement asynchronous
interfaces, or fixing the known async issues. Until someone
tackles those items, we can't think of adding those "s -t 1 2 3"'s in
all-stop. non-stop is a different issue.
My patch simply attempts at making all-stop multi-inferior behave
the same as multi-forks + all-stop worked ever since it was added, so
that we can continue lifting gdb's age old single-inferior design
restrictions. E.g., trying to resume all forks is still a very
limited experience, since GDB will only insert breakpoints in one
of the forks... DICOS doesn't have this issue (breakpoints are visible
to all processes), so resuming all inferiors is a feature that I can
claim is useable today on some targets.
I'm not saying that we should stick to this new switch forever, but
IMNSHO, making gdb a parallel debugger inevitably takes experimentation
and user feedback (this is nothing new: we can consider the multi-forks
the first experimentation).
--
Pedro Alves
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-30 10:51 [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] Pedro Alves
2009-05-30 13:10 ` Eli Zaretskii
2009-05-31 16:34 ` Doug Evans
@ 2009-06-01 14:29 ` Marc Khouzam
2009-06-03 13:49 ` Pedro Alves
2 siblings, 1 reply; 16+ messages in thread
From: Marc Khouzam @ 2009-06-01 14:29 UTC (permalink / raw)
To: Pedro Alves, gdb-patches
> -----Original Message-----
> From: Pedro Alves [mailto:pedro@codesourcery.com]
> Sent: May-30-09 6:52 AM
> To: gdb-patches@sourceware.org
> Cc: Marc Khouzam
> Subject: [RFC] Allowing all threads of all|current
> process(es) to be resumed [new command + docs]
>
> Hi guys,
>
> While moving the linux native multi-forks support ("info forks") into
> the generic multi-inferior framework I've ran into a little snag.
>
> 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. I'm thinking that the multi-forks behaviour
> should be the default, as it seems to be less surprising, and, it was
> here before...
>
> So, I've came up with this new command so that the user
> can select the behaviour desired. This currently only affects
> all-stop mode.
>
> What do you think of this?
>
> I'd prefer that GDB had notion of dynamic thread groups, a-la
> totalview, but I think we're a bit far for that yet, and
> it sounds like we'd still make use of something like this
> to affect the defaults.
>
> [Marc, you've guessed it, I'm CCing you because this may
> affect your current eclipse all-stop multi-process support. If this
> sticks, you'll just need to issue "set schedule-multiple on" once
> to get the current behaviour.]
Although it is possible, I don't believe anyone uses all-stop with
multi-process, we always use non-stop. So such a change is not
currently a big problem for Eclipse. So you get my vote for making
the behaviour more 'expected', as you suggest.
However, this whole thing forces me to finally take my head out
of the sand and address this scheduler-locking thing. As you may
guess, eclipse currently uses the GDB defaults for the all-stop
behaviour.
However, (and thanks to your explanation, which finally cleared things
up for me :-)), I think eclipse could/should take advantage of the
different options. Specifically, if a user is focused on a thread and
resumes: only that thread should be resumed (scheduler-locking on);
if the user if focused on an inferior: then all threads of that
inferior should be resumed (schedule-multiple off + scheduler-locking
off);
and if the user focuses on the entire debugging session: then
all threads of all inferiors should be resumed (schedule-multiple on +
scheduler-locking off). So, I like your new option, as it gives
more choices for the user. This makes all-stop resuming look more
like non-stop resuming.
Let me ask you, what is the way in non-stop to resume all threads
of the current process? -exec-continue is for a single thread,
-exec-continue --all is for all threads of all processes. Your
proposal addresses this issue for only for all-stop?
Thanks
marc
>
> --
> Pedro Alves
>
> 2009-05-30 Pedro Alves <pedro@codesourcery.com>
>
> * gdb.texinfo (All-Stop): Document new 'set schedule-multiple'
> command.
>
> 2009-05-30 Pedro Alves <pedro@codesourcery.com>
>
> * infrun.c (sched_multi): New global.
> (resume): If sched_multi is set, resume only threads of the
> current inferior.
> (prepare_to_proceed): Don't switch over to wait_ptid if we're
> resuming a different inferior, and sched_multi is off.
> (show_schedule_multiple): New.
> (_initialize_infrun): Register new "schedule-multiple" command.
> * inferior.h (sched_multi): Declare.
>
> ---
> gdb/doc/gdb.texinfo | 27 +++++++++++++++++++++
> gdb/inferior.h | 2 +
> gdb/infrun.c | 64
> +++++++++++++++++++++++++++++++++++++++++++---------
> 3 files changed, 83 insertions(+), 10 deletions(-)
>
> Index: src/gdb/doc/gdb.texinfo
> ===================================================================
> --- src.orig/gdb/doc/gdb.texinfo 2009-05-30
> 10:28:15.000000000 +0100
> +++ src/gdb/doc/gdb.texinfo 2009-05-30 11:36:02.000000000 +0100
> @@ -4650,6 +4650,33 @@ the current thread away from the thread
> Display the current scheduler locking mode.
> @end table
>
> +@cindex resume multiple processes
> +By default, @value{GDBN} allows only threads of the current inferior
> +to run in response to execution commands such as @code{continue}.
> +E.g., if @value{GDBN} is attached to two inferiors, each with two
> +threads, the @code{continue} command resumes only the two threads of
> +the current inferior. You can modify @value{GDBN}'s default behavior
> +by allowing all threads of all inferiors to be scheduled.
> +
> +@table @code
> +@kindex set schedule-multiple
> +@item set schedule-multiple
> +@cindex resume multiple processes
> +Sets the mode for scheduling multiple processes. When set, all
> +threads of all processes are allowed to run. When not set (which is
> +the default), only the threads of the current process are
> schedulable.
> +
> +@item show schedule-multiple
> +Display the current mode for scheduling multiple processes.
> +@end table
> +
> +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.
> +
> @node Non-Stop Mode
> @subsection Non-Stop Mode
>
> Index: src/gdb/infrun.c
> ===================================================================
> --- src.orig/gdb/infrun.c 2009-05-30 01:36:41.000000000 +0100
> +++ src/gdb/infrun.c 2009-05-30 11:35:01.000000000 +0100
> @@ -1091,6 +1091,11 @@ set_schedlock_func (char *args, int from
> }
> }
>
> +/* True if execution commands resume all threads of all processes by
> + default; otherwise, resume only threads of the current inferior
> + process. */
> +int sched_multi = 0;
> +
> /* Try to setup for software single stepping over the
> specified location.
> Return 1 if target_resume() should use hardware single step.
>
> @@ -1201,13 +1206,25 @@ a command like `return' or `jump' to con
> {
> ptid_t resume_ptid;
>
> - resume_ptid = RESUME_ALL; /* Default */
> -
> /* If STEP is set, it's a request to use hardware stepping
> facilities. But in that case, we should never
> use singlestep breakpoint. */
> gdb_assert (!(singlestep_breakpoints_inserted_p && step));
>
> + /* Decide the set of threads to ask the target to
> resume. Start
> + by assuming everything will be resumed, than narrow the set
> + by applying increasingly restricting conditions. */
> +
> + /* By default, resume all threads of all processes. */
> + resume_ptid = RESUME_ALL;
> +
> + /* Maybe resume only all threads of the current process. */
> + if ((!sched_multi || step) && target_supports_multi_process ())
> + {
> + resume_ptid = pid_to_ptid (ptid_get_pid (inferior_ptid));
> + }
> +
> + /* Maybe resume a single thread after all. */
> if (singlestep_breakpoints_inserted_p
> && stepping_past_singlestep_breakpoint)
> {
> @@ -1224,9 +1241,8 @@ a command like `return' or `jump' to con
> to support, and has no value. */
> resume_ptid = inferior_ptid;
> }
> -
> - if ((step || singlestep_breakpoints_inserted_p)
> - && tp->trap_expected)
> + else if ((step || singlestep_breakpoints_inserted_p)
> + && tp->trap_expected)
> {
> /* We're allowing a thread to run past a breakpoint it has
> hit, by single-stepping the thread with the breakpoint
> @@ -1240,8 +1256,7 @@ a command like `return' or `jump' to con
> breakpoint, not just the one at PC. */
> resume_ptid = inferior_ptid;
> }
> -
> - if (non_stop)
> + else if (non_stop)
> {
> /* With non-stop mode on, threads are always handled
> individually. */
> @@ -1394,11 +1409,19 @@ prepare_to_proceed (int step)
> || (scheduler_mode == schedlock_step
> && step));
>
> + /* Don't switch over to WAIT_PTID if scheduler locking is on. */
> + if (schedlock_enabled)
> + return 0;
> +
> + /* Don't switch over if we're about to resume some other process
> + other than WAIT_PTID's, and schedule-multiple is off. */
> + if (!sched_multi
> + && ptid_get_pid (wait_ptid) != ptid_get_pid (inferior_ptid))
> + return 0;
> +
> /* Switched over from WAIT_PID. */
> if (!ptid_equal (wait_ptid, minus_one_ptid)
> - && !ptid_equal (inferior_ptid, wait_ptid)
> - /* Don't single step WAIT_PID if scheduler locking is on. */
> - && !schedlock_enabled)
> + && !ptid_equal (inferior_ptid, wait_ptid))
> {
> struct regcache *regcache = get_thread_regcache (wait_ptid);
>
> @@ -5573,6 +5596,14 @@ show_non_stop (struct ui_file *file, int
> value);
> }
>
> +static void
> +show_schedule_multiple (struct ui_file *file, int from_tty,
> + struct cmd_list_element *c, const char *value)
> +{
> + fprintf_filtered (file,
> + _("Scheduling multiple processes
> simultaneously is %s.\n"),
> + value);
> +}
>
> void
> _initialize_infrun (void)
> @@ -5752,6 +5783,19 @@ step == scheduler locked during every si
> show_scheduler_mode,
> &setlist, &showlist);
>
> + add_setshow_boolean_cmd ("schedule-multiple", class_run,
> &sched_multi, _("\
> +Set mode for scheduling multiple processes simultaneously."), _("\
> +Show mode for scheduling multiple processes simultaneously."), _("\
> +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\
> +default), only the threads of the current process are made\n\
> +schedulable. The set of threads that are resumed is further\n\
> +refined by the scheduler-locking mode (see help set\n\
> +scheduler-locking)."),
> + NULL,
> + show_schedule_multiple,
> + &setlist, &showlist);
> +
> add_setshow_boolean_cmd ("step-mode", class_run,
> &step_stop_if_no_debug, _("\
> Set mode of the step operation."), _("\
> Show mode of the step operation."), _("\
> Index: src/gdb/inferior.h
> ===================================================================
> --- src.orig/gdb/inferior.h 2009-05-30 01:36:12.000000000 +0100
> +++ src/gdb/inferior.h 2009-05-30 01:37:18.000000000 +0100
> @@ -135,6 +135,8 @@ extern void clear_proceed_status (void);
>
> extern void proceed (CORE_ADDR, enum target_signal, int);
>
> +extern int sched_multi;
> +
> /* When set, stop the 'step' command if we enter a function which has
> no line number information. The normal behavior is that we step
> over such function. */
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-31 22:06 ` Pedro Alves
@ 2009-06-01 15:55 ` Doug Evans
2009-06-03 14:06 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Doug Evans @ 2009-06-01 15:55 UTC (permalink / raw)
To: Pedro Alves; +Cc: tromey, gdb-patches
On Sun, May 31, 2009 at 3:07 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> Re. 'c -t 1 2 3', and similars, you're skipping a lot of ground.
Whoa. Apologies for putting you through all that typing :-(. It was
just an off-the-cuff example and was certainly *not* aimed at
all-stop.
> Non-stop, however, avoids all these issues by working on top
> of an asynchronous target interface.
Indeed.
> My patch simply attempts at making all-stop multi-inferior behave
> the same as multi-forks + all-stop worked ever since it was added, so
> that we can continue lifting gdb's age old single-inferior design
> restrictions. E.g., trying to resume all forks is still a very
> limited experience, since GDB will only insert breakpoints in one
> of the forks... DICOS doesn't have this issue (breakpoints are visible
> to all processes), so resuming all inferiors is a feature that I can
> claim is useable today on some targets.
>
> I'm not saying that we should stick to this new switch forever, but
> IMNSHO, making gdb a parallel debugger inevitably takes experimentation
> and user feedback (this is nothing new: we can consider the multi-forks
> the first experimentation).
I guess I'm a bit confused (no claim is made that that's unexpected :-)).
I was offering an alternative. I'd still like to hear what you think
of adding a modifier to "continue", etc. instead. I'm not wedded to
it of course. In part it seemed like a good time to talk about the
two alternatives.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-06-01 14:29 ` Marc Khouzam
@ 2009-06-03 13:49 ` Pedro Alves
0 siblings, 0 replies; 16+ messages in thread
From: Pedro Alves @ 2009-06-03 13:49 UTC (permalink / raw)
To: Marc Khouzam; +Cc: gdb-patches
On Monday 01 June 2009 15:28:43, Marc Khouzam wrote:
> Let me ask you, what is the way in non-stop to resume all threads
> of the current process? -exec-continue is for a single thread,
> -exec-continue --all is for all threads of all processes.
Hmm, you must be thinking of something like this? Does it not work?
2008-11-17 Vladimir Prus <vladimir@codesourcery.com>
Implement continue/interrupt of thread groups.
* mi/mi-main.c (proceed_thread_callback): New.
(mi_cmd_exec_continue): If --thread-group is specified, resume all
threads in that group.
(interrupt_thread_callback): New.
(mi_cmd_exec_interrupt): If --thread-group is specified, interrupt
all threads in that group.
> Your proposal addresses this issue for only for all-stop?
Right, all-stop was my main concern. If we always resume
all threads of all inferiors, then even "(gdb) run" to start
up a new process ends up resuming other processes too.
--
Pedro Alves
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-06-01 15:55 ` Doug Evans
@ 2009-06-03 14:06 ` Pedro Alves
0 siblings, 0 replies; 16+ messages in thread
From: Pedro Alves @ 2009-06-03 14:06 UTC (permalink / raw)
To: Doug Evans; +Cc: tromey, gdb-patches
On Monday 01 June 2009 16:55:39, Doug Evans wrote:
> I guess I'm a bit confused (no claim is made that that's unexpected :-)).
> I was offering an alternative. I'd still like to hear what you think
> of adding a modifier to "continue", etc. instead. I'm not wedded to
> it of course. In part it seemed like a good time to talk about the
> two alternatives.
Well, it obviously sounds like something reasonable to have. OTOH, so
does the HPD's ptset prefix notation, something
like '(gdb) [1.2:4] step'. Of course, the -t switch could be easily
added today...
--
Pedro Alves
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-05-30 17:12 ` Eli Zaretskii
@ 2009-06-08 11:59 ` Pedro Alves
2009-06-09 4:01 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Pedro Alves @ 2009-06-08 11:59 UTC (permalink / raw)
To: gdb-patches, Eli Zaretskii
On Saturday 30 May 2009 18:12:09, Eli Zaretskii wrote:
> Thanks, the new patch for the manual and the NEWS entry are fine with
> me, but please consider the two remaining issues mentioned above.
Certainly! I'd really like you to be happy with this and here's my
next attempt at that. I've given a short example of why you'd want
either behaviour; used "resuming the execution", and switched to
mentioning the scheduler-locking precedence instead.
--
Pedro Alves
2009-06-08 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (All-Stop): Document new 'set schedule-multiple'
command.
2009-06-08 Pedro Alves <pedro@codesourcery.com>
* infrun.c (sched_multi): New global.
(resume): If sched_multi is set, resume only threads of the
current inferior.
(prepare_to_proceed): Don't switch over to wait_ptid if we're
resuming a different inferior, and sched_multi is off.
(show_schedule_multiple): New.
(_initialize_infrun): Register new "set schedule-multiple" command.
* inferior.h (sched_multi): Declare.
* NEWS: Mention new "schedule-multiple" setting.
---
gdb/NEWS | 5 ++++
gdb/doc/gdb.texinfo | 30 +++++++++++++++++++++++++
gdb/inferior.h | 2 +
gdb/infrun.c | 62 +++++++++++++++++++++++++++++++++++++++++++---------
4 files changed, 89 insertions(+), 10 deletions(-)
Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo 2009-06-08 12:11:55.000000000 +0100
+++ src/gdb/doc/gdb.texinfo 2009-06-08 12:50:38.000000000 +0100
@@ -4650,6 +4650,36 @@ the current thread away from the thread
Display the current scheduler locking mode.
@end table
+@cindex resume threads of multiple processes simultaneously
+By default, @value{GDBN} allows only threads of the current inferior
+to run in response to execution commands such as @code{continue},
+@code{next} or @code{step}. E.g., if @value{GDBN} is attached to two
+inferiors, each with two threads, the @code{continue} command resumes
+only the two threads of the current inferior. This is useful for
+example when debugging a program that forks, and you want to hold the
+fork parent stopped (so that for instance it doesn't run to exit),
+while debugging the child. In other ocasions, you are not interested
+in inspecting the current state of none of the processes @value{GDBN}
+is attached to, and you want to resume them all until any reports a
+breakpoint hit. You can modify @value{GDBN}'s default behavior by
+instead allowing all threads of all inferiors to run with the
+@w{@code{set schedule-multiple}} command.
+
+@table @code
+@kindex set schedule-multiple
+@item set schedule-multiple
+Set the mode for allowing threads of multiple processes to be resumed
+when an execution command is issued. When @code{on}, all threads of
+all processes are allowed to run. When @code{off}, only the threads
+of the current process are resumed. The default is @code{off}. The
+@code{scheduler-locking} mode takes precedence when set to @code{on},
+or while you are stepping and set to @code{step}.
+
+@item show schedule-multiple
+Display the current mode for resuming the execution of threads of
+multiple processes.
+@end table
+
@node Non-Stop Mode
@subsection Non-Stop Mode
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c 2009-06-08 12:11:55.000000000 +0100
+++ src/gdb/infrun.c 2009-06-08 12:54:00.000000000 +0100
@@ -1091,6 +1091,11 @@ set_schedlock_func (char *args, int from
}
}
+/* True if execution commands resume all threads of all processes by
+ default; otherwise, resume only threads of the current inferior
+ process. */
+int sched_multi = 0;
+
/* Try to setup for software single stepping over the specified location.
Return 1 if target_resume() should use hardware single step.
@@ -1201,13 +1206,25 @@ a command like `return' or `jump' to con
{
ptid_t resume_ptid;
- resume_ptid = RESUME_ALL; /* Default */
-
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(singlestep_breakpoints_inserted_p && step));
+ /* Decide the set of threads to ask the target to resume. Start
+ by assuming everything will be resumed, than narrow the set
+ by applying increasingly restricting conditions. */
+
+ /* By default, resume all threads of all processes. */
+ resume_ptid = RESUME_ALL;
+
+ /* Maybe resume only all threads of the current process. */
+ if (!sched_multi && target_supports_multi_process ())
+ {
+ resume_ptid = pid_to_ptid (ptid_get_pid (inferior_ptid));
+ }
+
+ /* Maybe resume a single thread after all. */
if (singlestep_breakpoints_inserted_p
&& stepping_past_singlestep_breakpoint)
{
@@ -1224,9 +1241,8 @@ a command like `return' or `jump' to con
to support, and has no value. */
resume_ptid = inferior_ptid;
}
-
- if ((step || singlestep_breakpoints_inserted_p)
- && tp->trap_expected)
+ else if ((step || singlestep_breakpoints_inserted_p)
+ && tp->trap_expected)
{
/* We're allowing a thread to run past a breakpoint it has
hit, by single-stepping the thread with the breakpoint
@@ -1240,8 +1256,7 @@ a command like `return' or `jump' to con
breakpoint, not just the one at PC. */
resume_ptid = inferior_ptid;
}
-
- if (non_stop)
+ else if (non_stop)
{
/* With non-stop mode on, threads are always handled
individually. */
@@ -1394,11 +1409,19 @@ prepare_to_proceed (int step)
|| (scheduler_mode == schedlock_step
&& step));
+ /* Don't switch over to WAIT_PTID if scheduler locking is on. */
+ if (schedlock_enabled)
+ return 0;
+
+ /* Don't switch over if we're about to resume some other process
+ other than WAIT_PTID's, and schedule-multiple is off. */
+ if (!sched_multi
+ && ptid_get_pid (wait_ptid) != ptid_get_pid (inferior_ptid))
+ return 0;
+
/* Switched over from WAIT_PID. */
if (!ptid_equal (wait_ptid, minus_one_ptid)
- && !ptid_equal (inferior_ptid, wait_ptid)
- /* Don't single step WAIT_PID if scheduler locking is on. */
- && !schedlock_enabled)
+ && !ptid_equal (inferior_ptid, wait_ptid))
{
struct regcache *regcache = get_thread_regcache (wait_ptid);
@@ -5551,6 +5574,13 @@ show_non_stop (struct ui_file *file, int
value);
}
+static void
+show_schedule_multiple (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ fprintf_filtered (file, _("\
+Resuming the execution of threads of all processes is %s.\n"), value);
+}
void
_initialize_infrun (void)
@@ -5730,6 +5760,18 @@ step == scheduler locked during every si
show_scheduler_mode,
&setlist, &showlist);
+ add_setshow_boolean_cmd ("schedule-multiple", class_run, &sched_multi, _("\
+Set mode for resuming threads of all processes."), _("\
+Show mode for resuming threads of all processes."), _("\
+When on, execution commands (such as 'continue' or 'next') resume all\n\
+threads of all processes. When off (which is the default), execution\n\
+commands only resume the threads of the current process. The set of\n\
+threads that are resumed is further refined by the scheduler-locking\n\
+mode (see help set scheduler-locking)."),
+ NULL,
+ show_schedule_multiple,
+ &setlist, &showlist);
+
add_setshow_boolean_cmd ("step-mode", class_run, &step_stop_if_no_debug, _("\
Set mode of the step operation."), _("\
Show mode of the step operation."), _("\
Index: src/gdb/inferior.h
===================================================================
--- src.orig/gdb/inferior.h 2009-06-08 12:11:55.000000000 +0100
+++ src/gdb/inferior.h 2009-06-08 12:11:57.000000000 +0100
@@ -135,6 +135,8 @@ extern void clear_proceed_status (void);
extern void proceed (CORE_ADDR, enum target_signal, int);
+extern int sched_multi;
+
/* When set, stop the 'step' command if we enter a function which has
no line number information. The normal behavior is that we step
over such function. */
Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS 2009-06-08 12:11:55.000000000 +0100
+++ src/gdb/NEWS 2009-06-08 12:11:57.000000000 +0100
@@ -305,6 +305,11 @@ show libthread-db-search-path
Control list of directories which GDB will search for appropriate
libthread_db.
+set schedule-multiple (on|off)
+show schedule-multiple
+ Allow GDB to resume all threads of all processes or only threads of
+ the current process.
+
* New native configurations
x86/x86_64 Darwin i[34567]86-*-darwin*
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-06-08 11:59 ` Pedro Alves
@ 2009-06-09 4:01 ` Eli Zaretskii
2009-06-11 11:59 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2009-06-09 4:01 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 8 Jun 2009 12:59:53 +0100
>
> On Saturday 30 May 2009 18:12:09, Eli Zaretskii wrote:
>
> > Thanks, the new patch for the manual and the NEWS entry are fine with
> > me, but please consider the two remaining issues mentioned above.
>
> Certainly! I'd really like you to be happy with this and here's my
> next attempt at that. I've given a short example of why you'd want
> either behaviour; used "resuming the execution", and switched to
> mentioning the scheduler-locking precedence instead.
Thanks.
> +@cindex resume threads of multiple processes simultaneously
> +By default, @value{GDBN} allows only threads of the current inferior
> +to run in response to execution commands such as @code{continue},
> +@code{next} or @code{step}. E.g., if @value{GDBN} is attached to two
> +inferiors, each with two threads, the @code{continue} command resumes
> +only the two threads of the current inferior. This is useful for
> +example when debugging a program that forks, and you want to hold the
> +fork parent stopped (so that for instance it doesn't run to exit),
> +while debugging the child. In other ocasions, you are not interested
> +in inspecting the current state of none of the processes @value{GDBN}
> +is attached to, and you want to resume them all until any reports a
> +breakpoint hit. You can modify @value{GDBN}'s default behavior by
> +instead allowing all threads of all inferiors to run with the
> +@w{@code{set schedule-multiple}} command.
This is indeed what I had in mind, but the wording needs some
improvement. I suggest this variant:
By default, when you issue one of the execution commands such as
@code{continue}, @code{next} or @code{step}, @value{GDBN} allows
only threads of the current inferior to run. For example, if
@value{GDBN} is attached to two inferiors, each with two threads,
the @code{continue} command resumes only the two threads of the
current inferior. This is useful, for example, when you debug a
program that forks and you want to hold the parent stopped (so that,
for instance, it doesn't run to exit), while you debug the child.
In other situations, you may not be interested in inspecting the
current state of any of the processes @value{GDBN} is attached to,
and you may want to resume them all until some breakpoint is hit.
In the latter case, you can instruct @value{GDBN} to allow all
threads of all the inferiors to run with the @w{@code{set
schedule-multiple}} command.
OK?
The rest of documentation-related hunks are fine with me.
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
2009-06-09 4:01 ` Eli Zaretskii
@ 2009-06-11 11:59 ` Pedro Alves
0 siblings, 0 replies; 16+ messages in thread
From: Pedro Alves @ 2009-06-11 11:59 UTC (permalink / raw)
To: gdb-patches, Eli Zaretskii
On Tuesday 09 June 2009 05:01:26, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
>
> This is indeed what I had in mind, but the wording needs some
> improvement. I suggest this variant:
>
> By default, when you issue one of the execution commands such as
> @code{continue}, @code{next} or @code{step}, @value{GDBN} allows
> only threads of the current inferior to run. For example, if
> @value{GDBN} is attached to two inferiors, each with two threads,
> the @code{continue} command resumes only the two threads of the
> current inferior. This is useful, for example, when you debug a
> program that forks and you want to hold the parent stopped (so that,
> for instance, it doesn't run to exit), while you debug the child.
> In other situations, you may not be interested in inspecting the
> current state of any of the processes @value{GDBN} is attached to,
> and you may want to resume them all until some breakpoint is hit.
> In the latter case, you can instruct @value{GDBN} to allow all
> threads of all the inferiors to run with the @w{@code{set
> schedule-multiple}} command.
>
> OK?
>
> The rest of documentation-related hunks are fine with me.
Thanks much! I've used it.
--
Pedro Alves
2009-06-11 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (All-Stop): Document new 'set schedule-multiple'
command.
2009-06-11 Pedro Alves <pedro@codesourcery.com>
* infrun.c (sched_multi): New global.
(resume): If sched_multi is set, resume only threads of the
current inferior.
(prepare_to_proceed): Don't switch over to wait_ptid if we're
resuming a different inferior, and sched_multi is off.
(show_schedule_multiple): New.
(_initialize_infrun): Register new "set schedule-multiple" command.
* inferior.h (sched_multi): Declare.
* NEWS: Mention new "schedule-multiple" setting.
---
gdb/NEWS | 5 ++++
gdb/doc/gdb.texinfo | 30 +++++++++++++++++++++++++
gdb/inferior.h | 2 +
gdb/infrun.c | 62 +++++++++++++++++++++++++++++++++++++++++++---------
4 files changed, 89 insertions(+), 10 deletions(-)
Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo 2009-06-11 12:38:51.000000000 +0100
+++ src/gdb/doc/gdb.texinfo 2009-06-11 12:44:02.000000000 +0100
@@ -4650,6 +4650,36 @@ the current thread away from the thread
Display the current scheduler locking mode.
@end table
+@cindex resume threads of multiple processes simultaneously
+By default, when you issue one of the execution commands such as
+@code{continue}, @code{next} or @code{step}, @value{GDBN} allows only
+threads of the current inferior to run. For example, if @value{GDBN}
+is attached to two inferiors, each with two threads, the
+@code{continue} command resumes only the two threads of the current
+inferior. This is useful, for example, when you debug a program that
+forks and you want to hold the parent stopped (so that, for instance,
+it doesn't run to exit), while you debug the child. In other
+situations, you may not be interested in inspecting the current state
+of any of the processes @value{GDBN} is attached to, and you may want
+to resume them all until some breakpoint is hit. In the latter case,
+you can instruct @value{GDBN} to allow all threads of all the
+inferiors to run with the @w{@code{set schedule-multiple}} command.
+
+@table @code
+@kindex set schedule-multiple
+@item set schedule-multiple
+Set the mode for allowing threads of multiple processes to be resumed
+when an execution command is issued. When @code{on}, all threads of
+all processes are allowed to run. When @code{off}, only the threads
+of the current process are resumed. The default is @code{off}. The
+@code{scheduler-locking} mode takes precedence when set to @code{on},
+or while you are stepping and set to @code{step}.
+
+@item show schedule-multiple
+Display the current mode for resuming the execution of threads of
+multiple processes.
+@end table
+
@node Non-Stop Mode
@subsection Non-Stop Mode
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c 2009-06-11 12:39:40.000000000 +0100
+++ src/gdb/infrun.c 2009-06-11 12:40:03.000000000 +0100
@@ -1091,6 +1091,11 @@ set_schedlock_func (char *args, int from
}
}
+/* True if execution commands resume all threads of all processes by
+ default; otherwise, resume only threads of the current inferior
+ process. */
+int sched_multi = 0;
+
/* Try to setup for software single stepping over the specified location.
Return 1 if target_resume() should use hardware single step.
@@ -1201,13 +1206,25 @@ a command like `return' or `jump' to con
{
ptid_t resume_ptid;
- resume_ptid = RESUME_ALL; /* Default */
-
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(singlestep_breakpoints_inserted_p && step));
+ /* Decide the set of threads to ask the target to resume. Start
+ by assuming everything will be resumed, than narrow the set
+ by applying increasingly restricting conditions. */
+
+ /* By default, resume all threads of all processes. */
+ resume_ptid = RESUME_ALL;
+
+ /* Maybe resume only all threads of the current process. */
+ if (!sched_multi && target_supports_multi_process ())
+ {
+ resume_ptid = pid_to_ptid (ptid_get_pid (inferior_ptid));
+ }
+
+ /* Maybe resume a single thread after all. */
if (singlestep_breakpoints_inserted_p
&& stepping_past_singlestep_breakpoint)
{
@@ -1224,9 +1241,8 @@ a command like `return' or `jump' to con
to support, and has no value. */
resume_ptid = inferior_ptid;
}
-
- if ((step || singlestep_breakpoints_inserted_p)
- && tp->trap_expected)
+ else if ((step || singlestep_breakpoints_inserted_p)
+ && tp->trap_expected)
{
/* We're allowing a thread to run past a breakpoint it has
hit, by single-stepping the thread with the breakpoint
@@ -1240,8 +1256,7 @@ a command like `return' or `jump' to con
breakpoint, not just the one at PC. */
resume_ptid = inferior_ptid;
}
-
- if (non_stop)
+ else if (non_stop)
{
/* With non-stop mode on, threads are always handled
individually. */
@@ -1394,11 +1409,19 @@ prepare_to_proceed (int step)
|| (scheduler_mode == schedlock_step
&& step));
+ /* Don't switch over to WAIT_PTID if scheduler locking is on. */
+ if (schedlock_enabled)
+ return 0;
+
+ /* Don't switch over if we're about to resume some other process
+ other than WAIT_PTID's, and schedule-multiple is off. */
+ if (!sched_multi
+ && ptid_get_pid (wait_ptid) != ptid_get_pid (inferior_ptid))
+ return 0;
+
/* Switched over from WAIT_PID. */
if (!ptid_equal (wait_ptid, minus_one_ptid)
- && !ptid_equal (inferior_ptid, wait_ptid)
- /* Don't single step WAIT_PID if scheduler locking is on. */
- && !schedlock_enabled)
+ && !ptid_equal (inferior_ptid, wait_ptid))
{
struct regcache *regcache = get_thread_regcache (wait_ptid);
@@ -5567,6 +5590,13 @@ show_non_stop (struct ui_file *file, int
value);
}
+static void
+show_schedule_multiple (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ fprintf_filtered (file, _("\
+Resuming the execution of threads of all processes is %s.\n"), value);
+}
void
_initialize_infrun (void)
@@ -5746,6 +5776,18 @@ step == scheduler locked during every si
show_scheduler_mode,
&setlist, &showlist);
+ add_setshow_boolean_cmd ("schedule-multiple", class_run, &sched_multi, _("\
+Set mode for resuming threads of all processes."), _("\
+Show mode for resuming threads of all processes."), _("\
+When on, execution commands (such as 'continue' or 'next') resume all\n\
+threads of all processes. When off (which is the default), execution\n\
+commands only resume the threads of the current process. The set of\n\
+threads that are resumed is further refined by the scheduler-locking\n\
+mode (see help set scheduler-locking)."),
+ NULL,
+ show_schedule_multiple,
+ &setlist, &showlist);
+
add_setshow_boolean_cmd ("step-mode", class_run, &step_stop_if_no_debug, _("\
Set mode of the step operation."), _("\
Show mode of the step operation."), _("\
Index: src/gdb/inferior.h
===================================================================
--- src.orig/gdb/inferior.h 2009-06-11 12:39:40.000000000 +0100
+++ src/gdb/inferior.h 2009-06-11 12:40:03.000000000 +0100
@@ -135,6 +135,8 @@ extern void clear_proceed_status (void);
extern void proceed (CORE_ADDR, enum target_signal, int);
+extern int sched_multi;
+
/* When set, stop the 'step' command if we enter a function which has
no line number information. The normal behavior is that we step
over such function. */
Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS 2009-06-11 12:38:51.000000000 +0100
+++ src/gdb/NEWS 2009-06-11 12:40:03.000000000 +0100
@@ -305,6 +305,11 @@ show libthread-db-search-path
Control list of directories which GDB will search for appropriate
libthread_db.
+set schedule-multiple (on|off)
+show schedule-multiple
+ Allow GDB to resume all threads of all processes or only threads of
+ the current process.
+
* New native configurations
x86/x86_64 Darwin i[34567]86-*-darwin*
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-06-11 11:59 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-30 10:51 [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs] Pedro Alves
2009-05-30 13:10 ` Eli Zaretskii
2009-05-30 16:01 ` Pedro Alves
2009-05-30 17:12 ` Eli Zaretskii
2009-06-08 11:59 ` Pedro Alves
2009-06-09 4:01 ` Eli Zaretskii
2009-06-11 11:59 ` Pedro Alves
2009-05-31 16:34 ` Doug Evans
2009-05-31 16:40 ` Doug Evans
2009-05-31 18:31 ` Tom Tromey
2009-05-31 18:38 ` Doug Evans
2009-05-31 22:06 ` Pedro Alves
2009-06-01 15:55 ` Doug Evans
2009-06-03 14:06 ` Pedro Alves
2009-06-01 14:29 ` Marc Khouzam
2009-06-03 13:49 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox