Doc: Update debugger topics

- Add info about PDB
- Edit info about setting up debuggers and add (existing)
  screenshots
- Update info about Add Breakpoints view
- Move some text around

Task-number: QTCREATORBUG-28778
Change-Id: Ice3813ef2d4b143ed1f9d246aa6c029829dee60f
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>

doc/qtcreator/src/debugger/creator-debug-views.qdoc

@@ -12,7 +12,7 @@
 
     \title Viewing Call Stack Trace
 
-    When the program being debugged is interrupted, \QC displays the nested
+    When the application being debugged is interrupted, \QC displays the nested
     function calls leading to the current position as a call stack trace. This
     stack trace is built up from call stack frames, each representing a
     particular function. For each function, \QC tries to retrieve the file name
@@ -24,14 +24,17 @@
     Since the call stack leading to the current position may originate or go
     through code for which no debug information is available, not all stack
     frames have corresponding source locations. Stack frames without
-    corresponding source locations are grayed out in the \uicontrol Stack view.
+    corresponding source locations are grayed out.
 
     If you click a frame with a known source location, the text editor jumps to
-    the corresponding location and updates the \uicontrol {Locals} and
-    \uicontrol {Expressions} views, making it seem like the program
-    was interrupted before entering the function.
+    the corresponding location and updates the
+    \l {Local Variables and Function Parameters}{Locals} and
+    \l {Evaluating Expressions}{Expressions} views, making it seem like the
+    application was interrupted before entering the function.
 
-    To find out which QML file is causing a Qt Quick 2 application to crash,
+    \section1 Loading QML Stack
+
+    To find out which QML file is causing a Qt Quick application to crash,
     select \uicontrol {Load QML Stack} in the context menu in the
     \uicontrol Stack view. The debugger tries to retrieve the JavaScript stack
     from the stopped executable and prepends the frames to the C++ frames,
@@ -66,8 +69,8 @@
 
         \li Executing some system calls
 
-        \li Changes in a block of memory at a particular address when a
-            program is running
+        \li Changes in a block of memory at a particular address when an
+            application is running
 
         \li Emitting QML signals
 
@@ -75,26 +78,30 @@
 
     \endlist
 
-    The interruption of a program by a breakpoint can be restricted with certain
-    conditions.
+    A breakpoint interrupts the application every time the application reaches
+    its location unless you specify a boolean condition for it. The breakpoint
+    evaluates the expression each time the application passes it, and the
+    application stops only if the condition evaluates to \c true.
+
+    \section1 Unclaimed and Claimed Breakpoints
 
     Breakpoints come in two varieties: \c unclaimed and \c claimed.
     An unclaimed breakpoint represents a task to interrupt the debugged
-    program and passes the control to you later. It has two states:
+    application and passes the control to you later. It has two states:
     \c pending and \c implanted.
 
     Unclaimed breakpoints are stored as a part of a session and exist
-    independently of whether a program is being debugged or not. They
+    independently of whether an application is being debugged or not. They
     are listed in the \uicontrol {Breakpoint Preset} view and in the
     editor using the \inlineimage icons/qtcreator-unclaimed-breakpoint-icon.png
     (\uicontrol {Unclaimed Breakpoint}) icon, when they refer to a position
     in code.
 
-    \image qtcreator-debugger-breakpoint-preset.png {Breakpoint Preset view}
+    \image qtcreator-debugger-breakpoint-preset.webp {Breakpoint Preset view}
 
     When a debugger starts, the debugging backend identifies breakpoints
     from the set of unclaimed breakpoints that might be handled by the
-    debugged program and claims them for its own exclusive use. Claimed
+    debugged application and claims them for its own exclusive use. Claimed
     breakpoints are listed in the \uicontrol {Breakpoints} view of the
     running debugger. This view only exists while the debugger is running.
 
@@ -115,11 +122,11 @@
     \uicontrol{Breakpoint Preset} view.
 
     When an implanted breakpoint is hit during the execution of the
-    debugged program, control is passed back to you.
-    You can then examine the state of the interrupted program, or
+    debugged application, control is passed back to you.
+    You can then examine the state of the interrupted application, or
     continue execution either line-by-line or continuously.
 
-    \image qtcreator-debug-breakpoints.png "Breakpoints view"
+    \image qtcreator-debug-breakpoints.webp {Breakpoints view}
 
     \section1 Adding Breakpoints
 
@@ -133,7 +140,7 @@
 
                 \li In the code editor, click the left margin or press \key F9
                     (\key F8 on \macos) on a particular line you want the
-                    program to stop.
+                    application to stop.
 
                 \li In the \uicontrol {Breakpoint Preset} view or the
                     \uicontrol Breakpoints view:
@@ -146,24 +153,68 @@
             \endlist
 
         \li In the \uicontrol {Breakpoint type} field, select the location in the
-            program code where you want the program to stop. The other options
-            to specify depend on the selected location.
-
-            \image qtcreator-add-breakpoint.png "Add Breakpoints" dialog
-
-        \li In the \uicontrol Condition field, set the condition to be evaluated
-            before stopping at the breakpoint if the condition evaluates as
-            true.
-
-        \li In the \uicontrol Ignore field, specify the number of times that the
-            breakpoint is ignored before the program stops.
-
-        \li In the \uicontrol Commands field, specify the commands to execute
-            when the program stops; one command on a line. GDB executes the
-            commands in the order in which they are specified.
+            application code where you want the application to stop.
 
+            \image qtcreator-add-breakpoint.webp {Add Breakpoints} dialog
     \endlist
 
+    Deselect the \uicontrol Enabled check box to make the breakpoint temporarily
+    inoperative as if you had deleted it, but keep the information about the
+    breakpoint, so that you can enable it again later.
+
+    The other options to specify depend on the location you select, such as file
+    name and line number, address, expression, or function name. The following
+    table summarizes the advanced options.
+
+    \table
+    \header
+        \li Option
+        \li Value
+    \row
+        \li \uicontrol Condition
+        \li The condition to evaluate before stopping at the breakpoint if the
+            condition evaluates as \c true.
+    \row
+        \li \uicontrol {Ignore count}
+        \li The number of times to ignore the breakpoint before the application
+            stops.
+    \row
+        \li \uicontrol {Thread specification}
+        \li
+    \row
+        \li \uicontrol Path
+        \li Determines how to specify the path when setting breakpoints:
+            \list
+                \li \uicontrol {Use Engine Default} is the preferred setting of
+                    the debugger engine.
+                \li \uicontrol {Use Full Path} passes the full path to avoid
+                    ambiguity if several modules contain files with the same
+                    name. This is the engine default for CDB and LLDB.
+                \li \uicontrol {Use File Name} passes the file name only. This is
+                    useful when the location of the source tree does not match
+                    the one used when building the modules. This is the engine
+                    default for GDB as using full paths can be slow with it.
+            \endlist
+    \row
+        \li \uicontrol Module
+        \li Specify the module (base name of the library or executable) for
+            function or file type breakpoints to speed up debugger startup
+            (CDB, LLDB).
+    \row
+        \li \uicontrol Commands
+        \li Commands to execute when the application stops. List one command per
+            line. GDB executes the commands in the order in which you specify
+            them.
+    \row
+        \li \uicontrol {Tracepoint only}
+        \li A \e tracepoint lets you log information about the application
+            without adding log statements or otherwise modifying your code.
+            You can set conditions for the tracepoint.
+    \row
+        \li \uicontrol Message
+        \li The tracepoint message to show in \l {Application Output}.
+    \endtable
+
     \if defined(qtcreator)
     \section1 Specifying Breakpoint Settings
 
@@ -171,6 +222,8 @@
     \uicontrol Preferences > \uicontrol Debugger. For more information,
     see \l{Debugger Preferences}.
 
+    \image qtcreator-debugger-general-options.png {General tab in Debugger preferences}
+
     To use a full absolute path in breakpoints, select the
     \uicontrol {Set breakpoints using a full absolute path} check box.
 
@@ -261,12 +314,12 @@
     disabled breakpoint. To re-enable a breakpoint, use any of the above
     methods.
 
-    With the notable exception of data breakpoints, breakpoints retain their
-    enabled or disabled state when the debugged program is restarted.
+    Other than data breakpoints retain their enabled or disabled state when the
+    debugged application is restarted.
 
     \section1 Setting Data Breakpoints
 
-    A \e {data breakpoint} stops the program when data is read or written at the
+    A \e {data breakpoint} stops the application when data is read or written at the
     specified address.
 
     To set a data breakpoint at an address:
@@ -291,8 +344,8 @@
     \uicontrol {Add Data Breakpoint at Object's Address} in the
     context menu to set the data breakpoint.
 
-    Data breakpoints will be disabled when the debugged program exits, as it
-    is unlikely that the used addresses will stay the same at the next program
+    Data breakpoints will be disabled when the debugged application exits, as it
+    is unlikely that the used addresses will stay the same at the next application
     launch. If you really want a data breakpoint to be active again, re-enable
     it manually.
 */
@@ -313,7 +366,7 @@
 
     \image qtcreator-locals.png {Locals view}
 
-    Whenever a program stops under the control of the debugger, it retrieves
+    Whenever an application stops under the control of the debugger, it retrieves
     information about the topmost stack frame and displays it in the
     \uicontrol {Locals} view. The \uicontrol Locals pane shows
     information about parameters of the function in that frame as well as the
@@ -416,7 +469,7 @@
 
     You can use the \uicontrol {Locals} and \uicontrol {Expressions} view to change
     the contents of variables of simple data types, for example, \c int, \c float,
-    \c QString and \c std::string when the program is interrupted. To do so,
+    \c QString and \c std::string when the application is interrupted. To do so,
     click the \uicontrol Value column, modify the value with the inplace editor,
     and press \key Enter (or \key Return).
 

doc/qtcreator/src/debugger/creator-only/creator-debugger-settings.qdoc

@@ -23,7 +23,7 @@
     output is sent to the system log. To override this behavior, select
     the \uicontrol {Force logging to console} check box. This sets
     \c QT_LOGGING_TO_CONSOLE=1 in the environment of the debugged
-    program, which effectively prevents storing debug output in
+    application, which effectively prevents storing debug output in
     system logs.
 
     \section1 Mapping Source Paths
@@ -96,7 +96,7 @@
     future, select the \uicontrol {Use automatic symbol cache} check box.
 
     To execute GDB commands after GDB has been started, but before the debugged
-    program is started or attached, and before the debugging helpers are
+    application is started or attached, and before the debugging helpers are
     initialized, enter them in the \uicontrol {Additional Startup Commands}
     field.
 

doc/qtcreator/src/debugger/creator-only/creator-debugger-setup.qdoc

@@ -1,4 +1,4 @@
-// Copyright (C) 2021 The Qt Company Ltd.
+// Copyright (C) 2023 The Qt Company Ltd.
 // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
 
 // **********************************************************************
@@ -15,48 +15,57 @@
 
     \title Setting Up Debugger
 
-    The main debugger settings are associated with the
-    \l{glossary-buildandrun-kit}{kit} you build and run your project with. To
+    The main debugger preferences are associated with the
+    \l{Adding Kits}{kit} you build and run your project with. To
     specify the debugger and compiler to use for each kit, select
     \uicontrol Edit > \uicontrol Preferences > \uicontrol Kits.
 
+    \image qtcreator-kits.png {Kits preferences}
+
     You need to set up the debugger only if the automatic setup fails because
-    the native debugger is missing (as is usually the case for the CDB debugger
-    on Windows, which you always must install yourself) or because the installed
-    version is not supported. For example, when your system does not have GDB
+    the native debugger is missing (for example, you must install the CDB
+    debugger on Windows yourself) or because \QC does not support the installed
+    version. For example, when your system does not have GDB
     installed or the installed version is outdated, and you want to use a locally
     installed replacement instead.
 
-    \note If you need to change the debugger to use for an automatically
-    detected \l{glossary-buildandrun-kit}{kit}, you can \uicontrol Clone the
-    kit and change the parameters in the clone. Make sure to select the cloned
-    kit for your project.
+    To change the debugger in an automatically detected kit, select
+    \uicontrol Edit > \uicontrol Preferences > \uicontrol Kits >
+    \uicontrol Clone to create a copy of the kit, and change the
+    parameters in the cloned kit. Make sure to enable the cloned kit
+    for your project.
 
     If the debugger you want to use is not automatically detected, select
     \uicontrol Edit > \uicontrol Preferences > \uicontrol Kits >
     \uicontrol Debuggers > \uicontrol Add to add it.
 
-    \note To use the debugging tools for Windows, you must install them and add
-    the Microsoft Symbol Server to the symbol search path of the
-    debugger. For more information, see \l{Setting CDB Paths on Windows}.
+    \image qtcreator-preferences-kits-debuggers.webp {Debuggers tab in Kits preferences}
 
-    \note To use the Free Software Foundation (FSF) version of GDB on \macos, you
-    must sign it and modify your \l{glossary-buildandrun-kit}{kit} settings.
+    To use the debugging tools for Windows, you must install them.
+    Optionally, you can set up the Microsoft Symbol Server if you need
+    symbol information from Microsoft modules that is not found locally.
+    For more information, see \l{Setting CDB Paths on Windows}.
 
-    This section describes the options you have for debugging C++ code and
-    installing the supported native debuggers. It also
-    applies for code in other compiled languages such as C, FORTRAN, Ada.
+    To use the Free Software Foundation (FSF) version of GDB on \macos, you
+    must sign it and modify your kit preferences.
 
-    For more information on the debugger modes, see
-    \l{Launching the Debugger in Different Modes}.
+    This section describes the options you have for debugging C++ and Python code
+    and installing the supported native debuggers. It also
+    applies to code in other compiled languages such as C, FORTRAN, and Ada.
+
+    For more information about launching the debugger in different modes, see
+    \l{Debugger Operating Modes}.
 
     \section1 Supported Native Debugger Versions
 
-    \QC supports native debuggers when working with compiled code. On
-    most supported platforms, the GNU Symbolic Debugger GDB can be used. On
-    Microsoft Windows, when using the Microsoft tool chain, the Microsoft
-    Console Debugger CDB is needed. On \macos and Linux, the LLDB debugger
-    can be used.
+    \QC supports native debuggers for debugging compiled code.
+    On most supported platforms, you can use the GNU Symbolic Debugger (GDB).
+    On Microsoft Windows, when using the Microsoft tool chain, you need the
+    Microsoft Console Debugger (CDB). On \macos and Linux, you can use the LLDB
+    debugger. On all supported platforms, you can use PDB to debug Python source
+    code.
+
+    \note You need a debugger version built with Python scripting support.
 
     The following table summarizes the support for debugging C++ code:
 
@@ -89,28 +98,26 @@
 
     \section2 Supported GDB Versions
 
-    Starting with version 3.1, \QC requires the Python scripting extension. GDB
-    builds without Python scripting are not supported anymore and will not work.
-    The minimum supported version is GDB 7.5 using Python version 2.7, or 3.3,
-    or newer.
+    Use GDB 7.5, or later, with the Python scripting extension and Python version
+    3.3, or later.
 
     For remote debugging using GDB and GDB server, the minimum supported version
     of GDB server on the target \l{glossary-device}{device} is 7.0.
 
     \section2 Supported CDB Versions
 
-    All versions of CDB targeting platforms supported by Qt are supported by
-    \QC.
+    \QC supports all versions of CDB targeting platforms that Qt supports.
 
     \section2 Supported LLDB Versions
 
     The LLDB native debugger has similar functionality to the GDB debugger. LLDB
-    is the default debugger in Xcode on \macos for supporting C++ on the desktop.
+    is the default debugger in Xcode on \macos for C++ on the desktop.
     LLDB is typically used with the Clang compiler (even though you can use it
     with GCC, too).
 
     On \macos you can use the LLDB version delivered with Xcode or build from source.
-    The minimum supported version is LLDB 320.4.
+    The minimum supported version is LLDB 320.4. You need a LLDB version built
+    with Python support.
 
     On Linux, the minimum supported version is LLDB 3.8.
 
@@ -182,22 +189,15 @@
     the required files in
     \c{"%ProgramFiles%\Debugging Tools for Windows"}.
 
-    \section3 Symbol Server
-
-    We highly recommend that you add the Microsoft Symbol Server to the
-    symbol search path of the debugger. The Symbol Server has debugging
-    information for the operating system libraries for debugging Windows
-    applications. For more information, see \l{Setting CDB Paths on Windows}.
-
     \section2 Debugging Tools for \macos
 
     The Qt binary distribution has both debug and release
-    variants of the libraries. But you have to explicitly tell the
+    variants of the libraries. However, you have to explicitly tell the
     runtime linker that you want to use the debug libraries even if
     your application is compiled as debug, as release is the default
     library.
 
-    If you use a qmake based project in \QC,  you can set a flag in
+    If you use a qmake based project in \QC, you can set a flag in
     your \l{glossary-run-config}{run configuration}, in
     \uicontrol Projects mode. In the run configuration, select
     \uicontrol{Use debug version of frameworks}.
@@ -210,6 +210,27 @@
 
     We recommend using the LLDB version that is delivered with the latest Xcode.
 
+    \section2 PDB
+
+    \l{https://docs.python.org/3/library/pdb.html}{PDB} is a source code debugger
+    for Python applications. You can use it to debug projects that have a
+    \l {Creating Widget-Based Qt for Python Applications}{.pyproject}
+    configuration file.
+
+    You must install Python and set the interpreter to use in \uicontrol Projects
+    > \uicontrol Run:
+
+    \image qtcreator-run-settings-python.webp {Run settings for a Python project}
+
+    Start debugging the \c main.py file. If you encounter problems, check the
+    active build target in the kit selector.
+
+    \QC does not support mixed-mode debugging, but you can attach GDB to the
+    Python interpreter to debug the C++ implementation of the corresponding
+    Python code. For more information, see
+    \l{https://doc.qt.io/qtforpython-6/tutorials/debugging/qtcreator/qtcreator.html}
+    {Debugging PySide with Qt Creator (Linux)}.
+
     \section1 Setting up FSF GDB for \macos
 
     To use FSF GDB on \macos, you must sign it and add it to the \QC
@@ -264,7 +285,7 @@
                 (\c $HOME/gdb72/bin/fsfgdb, but with an explicit value for
                 \c $HOME).
 
-        \li To use the debugger, add the kit in the \uicontrol {Build Settings}
+        \li To use the debugger, enable the kit in the \uicontrol {Build Settings}
             of the project.
 
     \endlist

doc/qtcreator/src/debugger/creator-only/creator-debugger.qdoc

@@ -35,7 +35,7 @@
             low level virtual machine (LLVM) project, LLDB.
         \li Debug QML and Java code and Qt Quick applications -
             QML/JavaScript debugger.
-        \li Debug Python source code - \c pdb.
+        \li Debug Python source code - PDB.
     \endlist
 
     The following sections describe how to set up, launch, and interact with the
@@ -130,44 +130,47 @@
     debugger, select the \inlineimage icons/qtcreator-debug-button.png
     (\uicontrol {Start Debugging of Startup Project}) button or press \key F5.
 
-    \QC checks whether the compiled program is up-to-date, and rebuilds and
+    \QC checks whether the compiled application is up-to-date, and rebuilds and
     deploys it if you set the \uicontrol {Build before deploying} field to
     build the whole project or the application to run and select he
     \uicontrol {Always deploy before running} check box in
     \uicontrol Edit > \uicontrol Preferences > \uicontrol {Build & Run} >
-    \uicontrol General. To debug the program without deploying
+    \uicontrol General. To debug the application without deploying
     it, select \uicontrol Debug > \uicontrol {Start Debugging} >
     \uicontrol {Start Debugging Without Deployment}.
 
-    The debugger then takes over and starts the program with suitable
+    The debugger then takes over and starts the application with suitable
     parameters.
 
     When using GDB or CDB as debug backend, you can specify additional commands
-    to execute before and after the backend and debugged program are started or
+    to execute before and after the backend and debugged application are started or
     attached in \uicontrol Edit > \uicontrol Preferences > \uicontrol Debugger >
     \uicontrol GDB and \uicontrol CDB. For more information, see
     \l{Debugger Preferences}.
 
-    To allow reading the user's default .gdbinit file on debugger startup,
+    To let the debugger read the user's default .gdbinit file when it starts,
     select the \uicontrol {Load .gdbinit file on startup} check box in
     GDB settings. For more information, see \l{Specifying GDB Settings}.
 
-    \note Starting a C++ program in the debugger can take a long time, typically
-    in the range of several seconds to minutes if complex features are used.
+    \note Starting a C++ application under the control of the debugger can take
+    a long time. Typically, in the range of several seconds to minutes if you use
+    complex features.
 
-    \section1 Launching the Debugger in Different Modes
+    For \l {Creating Widget-Based Qt for Python Applications}{Python} projects,
+    start debugging the \c main.py file. If you encounter problems, check the
+    active build target in the \l{Building for Multiple Platforms}{kit selector}.
+
+    \section1 Debugger Operating Modes
 
     The debugger plugin can run the native debuggers in various operating modes
-    depending on where and how the debugged process is started and run. Some of
+    depending on where and how you start and run the debugged process. Some of
     the modes are only available for a particular operating system or platform.
 
     In general, \key F5 and the \uicontrol {Start Debugging of Startup Project}
-    button are set up in a
-    way to start the operating mode that is commonly used in a given context. So
-    if the current project is set up as a C++ application using the \MinGW
-    toolchain targeting desktop Windows, the GDB engine will be started in Start
-    Internal mode. If the current project is a QML application using C++
-    plugins, a "mixed" QML/C++ engine will be started, with the C++ parts being
+    button start the operating mode that fits the context. So, for a C++
+    application that uses the \MinGW toolchain targeting desktop Windows, the GDB
+    engine starts in \e {start internal} mode. For a QML application that uses C++
+    plugins, a \e mixed QML/C++ engine starts, with the C++ parts being
     handled by GDB and GDB server remote debugging.
 
     Change the run configuration parameters (such as
@@ -179,24 +182,24 @@
 
     \list
 
-       \li \b{Start Internal} to debug applications developed inside \QC such as
-            a Qt based GUI application.
+       \li \e{Start internal} to debug applications developed inside \QC, such as
+            a Qt Widgets-based application.
 
-       \li \b{Start External} to start and debug processes without a proper \QC
+       \li \e{Start external} to start and debug processes without a proper \QC
             project setup, either locally or on a remote machine.
 
-       \li \b{Attach} to debug processes already started and running outside
+       \li \e{Attach} to debug processes already started and running outside
             \QC, either locally or on a remote machine.
 
-       \li \b{Core} to debug crashed processes on Unix.
+       \li \e{Core} to debug crashed processes on Unix.
 
-       \li \b{Post-mortem} to debug crashed processes on Windows.
+       \li \e{Post-mortem} to debug crashed processes on Windows.
 
     \endlist
 
-    \section2 Launching in Start Internal Mode
+    \section2 Start Internal
 
-    Start Internal mode is the default start mode for most projects, including
+    Start internal mode is the default start mode for most projects, including
     all projects using a desktop Qt version and plain C++ projects.
 
     If you need a console window to operate your application, for example
@@ -211,19 +214,19 @@
     override the console set in the Windows system environment variables.
     Note that the native console does not prompt on application exit.
 
-    To launch the debugger in Start Internal mode, click the
+    To launch the debugger in start internal mode, click the
     \uicontrol {Start Debugging} button for the active project.
 
     You can specify breakpoints before or after launching the debugger.
     For more information, see \l{Setting Breakpoints}.
 
-    \section2 Launching in Start External Mode
+    \section2 Start External
 
-    You can debug any executable already present on your local or on a remote
+    You can debug any executable on your local or on a remote
     machine without using a project. You specify a build and run kit that
     identifies the device to debug the application on.
 
-    While this mode does not strictly require a project to be opened in \QC,
+    While this mode does not strictly require a project to be open in \QC,
     opening it makes setting breakpoints and stepping through the code easier.
 
     To start and debug an external application:
@@ -261,7 +264,7 @@
             configuration to use.
     \endlist
 
-    \section2 Launching in Attach Mode
+    \section2 Attach
 
     You can attach the debugger to applications that are already running or
     instruct the debugger to attach to an application when it starts.
@@ -285,7 +288,7 @@
 
     To terminate the selected process, select \uicontrol {Kill Process}.
 
-    While this mode does not strictly require a project to be opened in \QC,
+    While this mode does not strictly require a project to be open in \QC,
     opening it makes setting breakpoints and stepping through the code easier.
 
     You can specify breakpoints before or after attaching the debugger to the
@@ -312,14 +315,14 @@
             process to start.
     \endlist
 
-    \section2 Launching in Core Mode
+    \section2 Core
 
-    The Core mode is used to inspect \e {core} files (crash dumps) that are
+    Use the core mode to inspect \e {core} files (crash dumps) that are
     generated from crashed processes on Linux and Unix systems if the system is
     set up to allow this.
 
     To enable the dumping of core files on a Unix system, enter the following
-    command in the shell from which the application will be launched:
+    command in the shell from which the application is launched:
 
     \code
     ulimit -c unlimited
@@ -350,12 +353,12 @@
             the \c sysroot to use instead of the default \c sysroot.
     \endlist
 
-    Also in this mode, using a properly configured project that has the
-    sources of the crashed program is not strictly necessary, but helpful.
+    Even though using a properly configured project that has the sources of the
+    crashed application is not strictly necessary, it is helpful.
 
-    \section2 Launching in Post-Mortem Mode
+    \section2 Post-Mortem
 
-    The post-mortem mode is available only on Windows, if you have installed the
+    The post-mortem mode is available only on Windows, if you installed the
     debugging tools for Windows.
 
     The \QC installation program asks you whether you want to register \QC as a
@@ -365,7 +368,7 @@
 
     You can launch the debugger in the post-mortem mode if an application
     crashes on Windows. Click the \uicontrol {Debug in \QC} button in the error
-    message that is displayed by the Windows operating system.
+    message from the Windows operating system.
 */
 
 /*!
@@ -552,43 +555,35 @@
     \title Debug Mode Views
 
     In the \uicontrol Debug mode, you can inspect the state of your
-    application while debugging. You can interact with the debugger
-    in many ways, including the following:
+    application while debugging.
+
+    \image qtcreator-debugger-views.webp {Debug mode views while debugging}
+
+    You can interact with the debugger in many ways:
 
     \list
 
-        \li Go through a program line-by-line or instruction-by-instruction.
-
-        \li Interrupt running programs.
+        \li Interrupt running applications.
 
         \li Set breakpoints.
 
+        \li Step through an application line-by-line or
+            instruction-by-instruction.
+
         \li Examine the contents of the call stack.
 
         \li Examine and modify contents of local and global variables.
 
         \li Examine and modify registers and memory contents of
-            the debugged program.
+            the debugged application.
 
         \li Examine the list of loaded shared libraries.
 
         \li Disassemble sections of code.
     \endlist
 
-    \QC displays the raw information from the native debuggers in a clear
-    and concise manner with the goal to simplify the debugging process as much
-    as possible without losing the power of the native debuggers.
-
-    In addition to the generic IDE functionality of the stack view, views
-    for locals and expressions, registers, and so on, \QC includes features to
-    make debugging Qt-based applications easy. The debugger plugin understands
-    the internal layout of several Qt classes, for example, QString, the Qt
-    containers, and most importantly QObject (and classes derived from it), as
-    well as most containers of the C++ Standard Library and some GCC extensions.
-    It uses this deeper understanding to present objects of such classes in a
-    useful way.
-
-    Interact with the program you are debugging in the following views.
+    The following table summarizes the \uicontrol Debug mode views with links to
+    more information.
 
     \table
     \header
@@ -597,12 +592,14 @@
         \li Learn More
     \row
         \li Stack
-        \li Examine the the nested function calls leading to the current position
+        \li Examine the nested function calls leading to the current position
             as a call stack trace.
         \li \l {Viewing Call Stack Trace}
     \row
-        \li Breakpoints
-        \li Set \e {breakpoints} with conditions make the application stop in
+        \li Breakpoint Preset
+
+            Breakpoints
+        \li Set \e {breakpoints} with conditions to make the application stop in
             a controlled way. A \e {watchpoint} stops the application when the
             value of an expression changes.
         \li \l {Setting Breakpoints}
@@ -658,17 +655,17 @@
 
     \section1 Managing Debug Views
 
-    The availability of views depends on whether
-    you are debugging C++ or QML. Frequently used views are shown by
-    default and rarely used ones are hidden. To change the default settings,
-    select \uicontrol View > \uicontrol Views, and then select views to
-    display or hide. Alternatively, you can enable or disable views from the
-    context menu of the title bar of any visible debug mode view.
+    When you are not debugging, the \uicontrol Debug mode shows the
+    \uicontrol {Debugger Preset} perspective:
 
-    \image qtcreator-debugger-views.png {Debug mode views}
+    \image qtcreator-debugger-views-initial.webp {Initial Debug mode views}
 
-    You can drag and drop the views in \QC to new positions on the screen. The
-    size and position of views are saved for future sessions. Select
+    During debugging, the mode shows the views that you usually need to
+    debug C++ or QML applications. To show other views or to hide views,
+    select \uicontrol Views.
+
+    You can drag the views in \QC to new positions on the screen. \QC saves the
+    size and position of views as a perspective for future sessions. Select
     \uicontrol View > \uicontrol Views > \uicontrol {Reset to Default Layout}
     to reset the views to their original sizes and positions.
 
@@ -680,13 +677,18 @@
 
     \section1 Customizing Debug Views
 
-    You can change the appearance and behavior of the debug views by specifying
-    settings in \uicontrol Preferences > \uicontrol Debugger. For example, you can:
+    To change the appearance and behavior of the debug views, set preferences
+    in \uicontrol Edit > \uicontrol Preferences > \uicontrol Debugger >
+    \uicontrol General.
+
+    \image qtcreator-debugger-general-options.png {General tab in Debugger preferences}
+
+    For example, you can:
 
     \list
         \li Use alternating row colors in debug views.
         \li Adopt font size changes from the main editor.
-        \li Have tooltips displayed in the main editor while you are debugging.
+        \li Show tooltips in the main editor while you are debugging.
         \li Close temporary source and memory views and switch to the previously
             used \QC mode when the debugger exits.
         \li Bring \QC to the foreground when the debugged application is
@@ -703,17 +705,19 @@
 
     \title Stopping Applications
 
-    Once the program starts running under the control of the debugger, it
-    behaves and performs as usual. You can interrupt a running C++ program by
-    selecting \uicontrol Debug > \uicontrol Interrupt. The program is
-    automatically interrupted when a breakpoint is hit.
+    Once the application starts running under the control of the debugger, it
+    behaves and performs as usual.
 
-    Once the program stops, \QC:
+    To interrupt a running C++ application, select \uicontrol Debug >
+    \uicontrol Interrupt. The debugger automatically interrupts
+    the application when it hits a \l {Setting Breakpoints}{breakpoint}.
+
+    Once the application stops, \QC:
 
     \list
 
         \li Retrieves data representing the \l{Viewing Call Stack Trace}
-            {call stack} at the program's current position.
+            {call stack} at the application's current position.
 
         \li Retrieves the contents of \l{Local Variables and Function Parameters}
             {local variables}.
@@ -725,6 +729,8 @@
             {Disassembler} views if you are debugging C++ based applications.
 
     \endlist
+    You can \l{Examining Data}{Examine} and change variables, set or remove
+    breakpoints, and then continue running the application.
 */
 
 /*!
@@ -753,7 +759,7 @@
        \li To leave the current function or subfunction, press \key {Shift+F11}
            (\key {Command+Shift+T} on \macos).
 
-       \li To continue running the program, press \key F5.
+       \li To continue running the application, press \key F5.
 
        \li To run to the line that has the cursor, press \key {Ctrl+F10}
            (\key {Shift+F8} on \macos).
@@ -763,7 +769,7 @@
 
     \endlist
 
-    You can continue executing the program until the current
+    You can continue executing the application until the current
     function completes or jump to an arbitrary position in the current function.
 
     \section1 Stepping Into Code
@@ -849,15 +855,15 @@
     \omit
     \section2 Creating Snapshots
 
-    A snapshot has the complete state of the debugged program at a time,
+    A snapshot has the complete state of the debugged application at a time,
     including the full memory contents.
 
-    To create snapshots of a debugged program, select \uicontrol {Create Snapshot}
+    To create snapshots of a debugged application, select \uicontrol {Create Snapshot}
     in the context menu in the \uicontrol {Debugger Perspectives} view.
 
     Double-click on entries in the \uicontrol {Debugger Perspectives} view to
     switch between snapshots. The debug mode views are updated to reflect the state
-    of the program at time of taking the snapshot.
+    of the application at time of taking the snapshot.
 
     \note Creating snapshots involves creating core files of the debugged process,
     requiring significant amount of disk space. For details, see
@@ -873,7 +879,7 @@
 
     \title Viewing Threads
 
-    If a multi-threaded program is interrupted, the \uicontrol Threads view or
+    If a multi-threaded application is interrupted, the \uicontrol Threads view or
     the combobox named \uicontrol Threads in the debugger status bar can be used
     to switch from one thread to another. The \uicontrol Stack view adjusts
     itself accordingly.
@@ -956,7 +962,7 @@
     values of registers that recently have changed are highlighted in red and empty
     register values as well as leading zeroes are grayed out.
 
-    In addition it is possible to edit the content of registers while the program is
+    In addition it is possible to edit the content of registers while the application is
     stopped. This applies to both General-purpose and Special-purpose registers.
     Registers can be edited in the standard condensed view or in their particular parts
     if the register is displayed expanded.