zephyrproject-rtos · carlescufi · Sep 6, 2023 · Mar 31, 2023 · Mar 31, 2023 · Mar 31, 2023
diff --git a/doc/develop/application/index.rst b/doc/develop/application/index.rst
@@ -431,7 +431,7 @@ should know about.
 
 * :makevar:`SHIELD`: see :ref:`shields`
 
-* :makevar:`ZEPHYR_MODULES`: A CMake list containing absolute paths of
+* :makevar:`ZEPHYR_MODULES`: A `CMake list`_ containing absolute paths of
   additional directories with source code, Kconfig, etc. that should be used in
   the application build. See :ref:`modules` for details. If you set this
   variable, it must be a complete list of all modules to use, as the build
@@ -1054,169 +1054,6 @@ again.
    target name, for example ``west build -t run_qemu`` or ``ninja run_qemu``
    for QEMU.
 
-.. _application_debugging:
-
-Application Debugging
-*********************
-
-This section is a quick hands-on reference to start debugging your
-application with QEMU. Most content in this section is already covered in
-`QEMU`_ and `GNU_Debugger`_ reference manuals.
-
-.. _QEMU: http://wiki.qemu.org/Main_Page
-
-.. _GNU_Debugger: http://www.gnu.org/software/gdb
-
-In this quick reference, you'll find shortcuts, specific environmental
-variables, and parameters that can help you to quickly set up your debugging
-environment.
-
-The simplest way to debug an application running in QEMU is using the GNU
-Debugger and setting a local GDB server in your development system through QEMU.
-
-You will need an :abbr:`ELF (Executable and Linkable Format)` binary image for
-debugging purposes.  The build system generates the image in the build
-directory.  By default, the kernel binary name is :file:`zephyr.elf`. The name
-can be changed using :kconfig:option:`CONFIG_KERNEL_BIN_NAME`.
-
-GDB server
-==========
-
-We will use the standard 1234 TCP port to open a :abbr:`GDB (GNU Debugger)`
-server instance. This port number can be changed for a port that best suits the
-development environment. There are multiple ways to do this. Each way starts a
-QEMU instance with the processor halted at startup and with a GDB server
-instance listening for a connection.
-
-Running QEMU directly
-~~~~~~~~~~~~~~~~~~~~~
-
-You can run QEMU to listen for a "gdb connection" before it starts executing any
-code to debug it.
-
-.. code-block:: bash
-
-   qemu -s -S <image>
-
-will setup Qemu to listen on port 1234 and wait for a GDB connection to it.
-
-The options used above have the following meaning:
-
-* ``-S`` Do not start CPU at startup; rather, you must type 'c' in the
-  monitor.
-* ``-s`` Shorthand for :literal:`-gdb tcp::1234`: open a GDB server on
-  TCP port 1234.
-
-
-Running QEMU via :command:`ninja`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Run the following inside the build directory of an application:
-
-.. code-block:: console
-
-   ninja debugserver
-
-QEMU will write the console output to the path specified in
-:makevar:`${QEMU_PIPE}` via CMake, typically :file:`qemu-fifo` within the build
-directory. You may monitor this file during the run with :command:`tail -f
-qemu-fifo`.
-
-Running QEMU via :command:`west`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Run the following from your project root:
-
-.. code-block:: console
-
-   west build -t debugserver_qemu
-
-QEMU will write the console output to the terminal from which you invoked
-:command:`west`.
-
-Configuring the :command:`gdbserver` listening device
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Kconfig option :kconfig:option:`CONFIG_QEMU_GDBSERVER_LISTEN_DEV` controls
-the listening device, which can be a TCP port number or a path to a character
-device. GDB releases 9.0 and newer also support Unix domain sockets.
-
-If the option is unset, then the QEMU invocation will lack a ``-s`` or a
-``-gdb`` parameter. You can then use the :envvar:`QEMU_EXTRA_FLAGS` shell
-environment variable to pass in your own listen device configuration.
-
-GDB client
-==========
-
-Connect to the server by running :command:`gdb` and giving these commands:
-
-.. code-block:: bash
-
-   $ path/to/gdb path/to/zephyr.elf
-   (gdb) target remote localhost:1234
-   (gdb) dir ZEPHYR_BASE
-
-.. note::
-
-   Substitute the correct :ref:`ZEPHYR_BASE <important-build-vars>` for your
-   system.
-
-You can use a local GDB configuration :file:`.gdbinit` to initialize your GDB
-instance on every run. Your home directory is a typical location for
-:file:`.gdbinit`, but you can configure GDB to load from other locations,
-including the directory from which you invoked :command:`gdb`. This example
-file performs the same configuration as above:
-
-.. code-block:: none
-
-   target remote localhost:1234
-   dir ZEPHYR_BASE
-
-Alternate interfaces
-~~~~~~~~~~~~~~~~~~~~
-
-GDB provides a curses-based interface that runs in the terminal. Pass the ``--tui``
-option when invoking :command:`gdb` or give the ``tui enable`` command within
-:command:`gdb`.
-
-.. note::
-
-   The GDB version on your development system might not support the ``--tui``
-   option. Please make sure you use the GDB binary from the SDK which
-   corresponds to the toolchain that has been used to build the binary.
-
-Finally, the command below connects to the GDB server using the :abbr:`DDD
-(Data Display Debugger)`, a graphical frontend for GDB. The following command
-loads the symbol table from the ELF binary file, in this instance,
-:file:`zephyr.elf`.
-
-.. code-block:: bash
-
-   ddd --gdb --debugger "gdb zephyr.elf"
-
-Both commands execute :command:`gdb`. The command name might
-change depending on the toolchain you are using and your cross-development
-tools.
-
-:command:`ddd` may not be installed in your
-development system by default. Follow your system instructions to install
-it. For example, use :command:`sudo apt-get install ddd` on an Ubuntu system.
-
-Debugging
-=========
-
-As configured above, when you connect the GDB client, the application will be
-stopped at system startup. You may set breakpoints, step through code, etc. as
-when running the application directly within :command:`gdb`.
-
-.. note::
-
-   :command:`gdb` will not print the system console output as the application runs,
-   unlike when you run a native application in GDB directly. If you just
-   :command:`continue` after connecting the client, the application will run,
-   but nothing will appear to happen. Check the console output as described
-   above.
-
 .. _custom_board_definition:
 
 Custom Board, Devicetree and SOC Definitions
@@ -1449,136 +1286,7 @@ Cache variable:
    :goals: build
    :compact:
 
-
-
-Debug with Eclipse
-******************
-
-Overview
-========
-
-CMake supports generating a project description file that can be imported into
-the Eclipse Integrated Development Environment (IDE) and used for graphical
-debugging.
-
-The `GNU MCU Eclipse plug-ins`_ provide a mechanism to debug ARM projects in
-Eclipse with pyOCD, Segger J-Link, and OpenOCD debugging tools.
-
-The following tutorial demonstrates how to debug a Zephyr application in
-Eclipse with pyOCD in Windows. It assumes you have already installed the GCC
-ARM Embedded toolchain and pyOCD.
-
-Set Up the Eclipse Development Environment
-==========================================
-
-#. Download and install `Eclipse IDE for C/C++ Developers`_.
-
-#. In Eclipse, install the GNU MCU Eclipse plug-ins by opening the menu
-   ``Window->Eclipse Marketplace...``, searching for ``GNU MCU Eclipse``, and
-   clicking ``Install`` on the matching result.
-
-#. Configure the path to the pyOCD GDB server by opening the menu
-   ``Window->Preferences``, navigating to ``MCU``, and setting the ``Global
-   pyOCD Path``.
-
-Generate and Import an Eclipse Project
-======================================
-
-#. Set up a GNU Arm Embedded toolchain as described in
-   :ref:`toolchain_gnuarmemb`.
-
-#. Navigate to a folder outside of the Zephyr tree to build your application.
-
-   .. code-block:: console
-
-      # On Windows
-      cd %userprofile%
-
-   .. note::
-      If the build directory is a subdirectory of the source directory, as is
-      usually done in Zephyr, CMake will warn:
-
-      "The build directory is a subdirectory of the source directory.
-
-      This is not supported well by Eclipse.  It is strongly recommended to use
-      a build directory which is a sibling of the source directory."
-
-#. Configure your application with CMake and build it with ninja. Note the
-   different CMake generator specified by the ``-G"Eclipse CDT4 - Ninja"``
-   argument. This will generate an Eclipse project description file,
-   :file:`.project`, in addition to the usual ninja build files.
-
-   .. zephyr-app-commands::
-      :tool: all
-      :app: %ZEPHYR_BASE%\samples\synchronization
-      :host-os: win
-      :board: frdm_k64f
-      :gen-args: -G"Eclipse CDT4 - Ninja"
-      :goals: build
-      :compact:
-
-#. In Eclipse, import your generated project by opening the menu
-   ``File->Import...`` and selecting the option ``Existing Projects into
-   Workspace``. Browse to your application build directory in the choice,
-   ``Select root directory:``. Check the box for your project in the list of
-   projects found and click the ``Finish`` button.
-
-Create a Debugger Configuration
-===============================
-
-#. Open the menu ``Run->Debug Configurations...``.
-
-#. Select ``GDB PyOCD Debugging``, click the ``New`` button, and configure the
-   following options:
-
-   - In the Main tab:
-
-     - Project: ``my_zephyr_app@build``
-     - C/C++ Application: :file:`zephyr/zephyr.elf`
-
-   - In the Debugger tab:
-
-     - pyOCD Setup
-
-       - Executable path: :file:`${pyocd_path}\\${pyocd_executable}`
-       - Uncheck "Allocate console for semihosting"
-
-     - Board Setup
-
-       - Bus speed: 8000000 Hz
-       - Uncheck "Enable semihosting"
-
-     - GDB Client Setup
-
-       - Executable path example (use your ``GNUARMEMB_TOOLCHAIN_PATH``):
-         :file:`C:\\gcc-arm-none-eabi-6_2017-q2-update\\bin\\arm-none-eabi-gdb.exe`
-
-   - In the SVD Path tab:
-
-     - File path: :file:`<workspace
-       top>\\modules\\hal\\nxp\\mcux\\devices\\MK64F12\\MK64F12.xml`
-
-     .. note::
-	This is optional. It provides the SoC's memory-mapped register
-	addresses and bitfields to the debugger.
-
-#. Click the ``Debug`` button to start debugging.
-
-RTOS Awareness
-==============
-
-Support for Zephyr RTOS awareness is implemented in `pyOCD v0.11.0`_ and later.
-It is compatible with GDB PyOCD Debugging in Eclipse, but you must enable
-CONFIG_DEBUG_THREAD_INFO=y in your application.
-
-
-
 .. _CMake: https://www.cmake.org
 .. _CMake introduction: https://cmake.org/cmake/help/latest/manual/cmake.1.html#description
-.. _Eclipse IDE for C/C++ Developers: https://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/oxygen2
-.. _GNU MCU Eclipse plug-ins: https://gnu-mcu-eclipse.github.io/plugins/install/
-.. _pyOCD v0.11.0: https://github.com/mbedmicro/pyOCD/releases/tag/v0.11.0
 .. _CMake list: https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#lists
-.. _add_subdirectory(): https://cmake.org/cmake/help/latest/command/add_subdirectory.html
-.. _using Chocolatey: https://chocolatey.org/packages/RapidEE
 .. _example-application: https://github.com/zephyrproject-rtos/example-application