Different types of debug

The Armv8-A architecture can support two types of debug: external debug and self-hosted debug. Two types of debug operation can be performed: non-invasive debug and invasive debug.

We will describe external and self-hosted debug, and invasive versus non-invasive debug. We are providing an overview only, and do not provide detail about how to program an Armv8-A processor to use any particular type of debug.

External debug

External debug occurs when the debugger is external to the processor being debugged. For example, external debug is taking place if a debugger that is running on a host machine is debugging an Armv8-A processor that is available on a separate development board. Another example of external debug is a debugger that is running on one processor and debugging another processor on the same SoC.

External debug is usually used when doing chip validation and bring-up, or when working with bare-metal environments. Generally, external debug relies on a physical connector, for example JTAG, or Serial Wire Debug (SWD) on the target being debugged.

External debug also requires a debug adapter to be connected between the target being debugged and the host machine running the debugger. The following diagram shows the debug adapter connection between a host machine running a debugger and a debug target:

                    External debug diagram

Self-hosted debug

Self-hosted debug occurs when the debugger and the software being debugged run on the same processor. A good example is gdbserver, which is used for Linux application debug. Gdbserver is a program that runs alongside a Linux application, and allows a debug environment like GDB or the Arm Debugger to debug the application.

This diagram shows how gdbserver interacts with an Operating System (OS) application and a debugger:

                      Diagram of self-hosted debug

Even though the debugger attached to gdbserver usually runs off-target, gdbserver is still classed as self-hosted debug.

Self-hosted debug is usually used with debugging applications that are running under an OS, or when physical debug connectors are not available.

Invasive debug

When using invasive debug, the act of debugging changes the processor state in a subtle way. For example, when a breakpoint is set using a debugger, the processor stops when the breakpoint is hit, and the timing of the program being debugged changes.

Some familiar debug methods are invasive debug methods. These include stepping through code, viewing memory, setting breakpoints and watchpoints, and viewing registers.

Usually, the subtle changes introduced using invasive debug techniques do not affect the general execution of the program. However, some bugs, for example problems related to timing, might be sensitive to these subtle changes. This means that invasive debug techniques are not suitable for investigating this type of bug.

Non-invasive debug

In contrast to invasive debug, non-invasive debug does not change the processor state in any way.

For example, generating and collecting trace data from a target will usually not affect the processor, so trace is usually classified as non-invasive debug. Other operations that are usually classified as non-invasive debug are use of the Performance Monitoring Unit (PMU) and performing Program Counter (PC) sampling.

Previous Next