Armv8-A debug

Armv8-A supports both self-hosted debug and external debug. This section of the guide deals with the self-hosted debug features that are supported in the Armv8-A architecture. External debug provides a less detailed overview of external debug. 

Self-hosted debug

This self-hosted debug model is used when the debugger is hosted on the Processing Element (PE) that is being debugged. Debug exceptions are the basis of the self-hosted debug model. The debugger programs the debug logic to generate debug events. These debug events then generate debug exceptions. 

Debug exceptions are synchronous exceptions that are routed to the Exception level (EL) where the debugger is hosted. The EL is referred to as ELd.  The ELd debug target Exception level is the EL where the debugger is hosted. The debugger code executes like an exception handler code at ELd.

Possible values for ELd are EL1 or EL2. It is possible to route debug exceptions to EL3, when EL3 is using AArch32.

Self-hosted debug supports the following debug models, depending on where the debugger is hosted and its abilities:

  • Application debugging
  • Kernel debugging
  • OS debugging
  • Hypervisor debugging

Let’s look at each of these in detail.

Application debugging

Application debugging enables the debugging of application code that is executing at EL0 by a debugger that is executing at EL1. Debug exceptions can be generated from an application execution (EL0) and handled by an operating system (EL1). Application debugging allows the operating system to debug its applications by hosting the debugger code as the exception handler code at EL1.

The following diagram shows application debugging:

Kernel debugging

Kernel debugging enables the debugging of code that is executing at EL0 and EL1 by a debugger that is executing at EL1. Debug exceptions can be generated from both EL0 and EL1 and are handled at EL1. Kernel debugging allows the operating system to debug its own software and applications by hosting the debugger code as the exception handler code at EL1. The following diagram shows kernel debugging:

Operating system debugging

Operating system (OS) debugging enables the debugging of code that is executing at EL0 and EL1 by a debugger that is executing at EL2. Debug exceptions can be generated from both EL0 and EL1 and are handled at EL2. OS debugging allows the hypervisor to debug a guest operating system.

OS debugging allows hypervisor to debug code that is executing at EL0 and EL1 by hosting the debugger code as the exception handler code at EL2.

The following diagram shows OS debugging:

Hypervisor debugging

Hypervisor debugging enables the debugging of code that is executing at EL0, EL1, and EL2 by a debugger that is executing at EL2. Debug exceptions can be generated from EL0, EL1, and EL2, and are handled at EL2. Hypervisor debugging allows the hypervisor to debug its own software.

Hypervisor debugging allows the hypervisor to debug code that is executed at EL0, EL1, and EL2, by hosting the debugger code as the exception handler code at EL2.

The following diagram shows hypervisor debugging:

Self-hosted debug is also called monitor mode debug. In self-hosted debug model, Debug registers are accessed using System Register Interface when in AArch64 state, and using Coprocessor Interface when in AArch32 State. Self-hosted debug registers are prefixed with MD, for example MDSCR_EL1. The registers that are shared between self-hosted debug model and external debug model are prefixed with DBG, for example DBGBVR0_EL1.

Some of the important Monitor debug registers are:

  • MDSCR_EL1, Monitor debug System Control Register
  • MDCR_EL2, Monitor debug Configuration Register (EL2)
Previous Next