diff options
author | Pedro Alves <pedro@palves.net> | 2021-11-30 19:52:11 +0000 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2022-07-12 18:11:29 +0100 |
commit | d21d919bc1d75f89140218f0d5702d0afff41209 (patch) | |
tree | 023099487c0398411c7a8eefc669dcb5b315512c | |
parent | 3da5576c911a0f3fc608471f1486dc6db11052ef (diff) | |
download | gdb-d21d919bc1d75f89140218f0d5702d0afff41209.zip gdb-d21d919bc1d75f89140218f0d5702d0afff41209.tar.gz gdb-d21d919bc1d75f89140218f0d5702d0afff41209.tar.bz2 |
Improve "set scheduler-locking" documentation
This improves the "set scheduler-locking" documentation in the GDB
manual:
- Use a table to describe the four available modes.
- Describe "step" in terms of "on" and "off".
- Tweak the "replay" mode's description to describe replay first
instead of recording, and also mention how the mode behaves during
normal execution.
- Say what is the default mode.
Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce
-rw-r--r-- | gdb/doc/gdb.texinfo | 40 |
1 files changed, 27 insertions, 13 deletions
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 562e4c1..9a8b010 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -6939,19 +6939,33 @@ locking the OS scheduler to allow only a single thread to run. @cindex scheduler locking mode @cindex lock scheduler Set the scheduler locking mode. It applies to normal execution, -record mode, and replay mode. If it is @code{off}, then there is no -locking and any thread may run at any time. If @code{on}, then only -the current thread may run when the inferior is resumed. The -@code{step} mode optimizes for single-stepping; it prevents other -threads from preempting the current thread while you are stepping, so -that the focus of debugging does not change unexpectedly. Other -threads never get a chance to run when you step, and they are -completely free to run when you use commands like @samp{continue}, -@samp{until}, or @samp{finish}. However, unless another thread hits a -breakpoint during its timeslice, @value{GDBN} does not change the -current thread away from the thread that you are debugging. The -@code{replay} mode behaves like @code{off} in record mode and like -@code{on} in replay mode. +record mode, and replay mode. @var{mode} can be one of +the following: + +@table @code +@item off +There is no locking and any thread may run at any time. + +@item on +Only the current thread may run when the inferior is resumed. + +@item step +Behaves like @code{on} when stepping, and @code{off} otherwise. +Threads other than the current never get a chance to run when you +step, and they are completely free to run when you use commands like +@samp{continue}, @samp{until}, or @samp{finish}. + +This mode optimizes for single-stepping; it prevents other threads +from preempting the current thread while you are stepping, so that the +focus of debugging does not change unexpectedly. However, unless +another thread hits a breakpoint during its timeslice, @value{GDBN} +does not change the current thread away from the thread that you are +debugging. + +@item replay +Behaves like @code{on} in replay mode, and @code{off} in either record +mode or during normal execution. This is the default mode. +@end table @item show scheduler-locking Display the current scheduler locking mode. |