Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]

[Eli Zaretskii <eliz at gnu dot org>]

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