Debug exceptions

In the self-hosted debug model, debug logic is configured for a debug event to cause debug exceptions. The Processing Element (PE) can only generate debug exceptions on debug events.

The debugger program is installed as the exception handler code, which is a higher level of system software that handles debug exceptions and programs the Debug system registers. The debugger program that runs in the debug exceptions are synchronous exceptions that are routed to an Exception Level (EL) where the debugger is hosted. The EL where a debugger is hosted is called debug target Exception level (ELd). The debugger code executes like an exception handler code at the ELd. Possible values for ELd are EL1 or EL2. It is possible to route debug exceptions to EL3 when EL3 is using AArch32.

On taking a debug exception to ELd, the debugger code can interpret the cause of exception from the following:

  • The event type and syndrome that is encoded in the ESR_ELx register
  • For a Watchpoint exception, FAR_ELx indicates the watchpointed address.

    Self-hosted debug supports the following debug exceptions:

  • Breakpoint instruction: This event is generated whenever the PE executes a BRK instruction.
  • Breakpoint: This event is generated whenever the PE tries to execute an instruction from a particular address.
  • Watchpoint: This event is generated whenever the PE accesses data from a particular address.
  • Software step: This event is generated immediately after the PE executes an instruction.

Breakpoints and watchpoints are resources that are shared between self-hosted and external debuggers. If halt mode debug is enabled, a watchpoint or breakpoint event causes the PE to enter debug state. Otherwise, a debug exception is generated if self-hosted debug is enabled.

Breakpoint Instruction exception

Whenever the breakpoint instruction, BRK, is committed for execution, the PE takes a Breakpoint Instruction exception. The Breakpoint Instruction exception cannot be masked. This means that the Breakpoint exceptions are always generated when the PE attempts to execute a BRK instruction. The Breakpoint Instruction exception is also called a software breakpoint.

The debugger code replaces the instruction in the program with a BRK instruction wherever it wants to halt the execution of a program. On exception, the debugger code replaces the BRK instruction with the original instruction before returning from the debug exception.

The following diagram illustrates the Breakpoint Instruction exception when the PE executes a BRK instruction at EL0:

 
Breakpoint exception

A Breakpoint exception is generated whenever the PE tries to execute an instruction from a particular address. There are hardware breakpoint registers that can be programmed with the address of the application code. When the PE attempts to execute an instruction from the programmed address, it generates a Breakpoint exception. Breakpoint setup uses hardware registers, so is commonly called a hardware breakpoint.

Here are instructions for programming a Breakpoint exception:

  1. The debugger programs the address of the instruction into the breakpoint value register, DBGBVR.
  2. The debugger enables the breakpoint in the breakpoint control register, DBGBCR, by setting the enable bit DBGBCR.E to generate the Breakpoint exception.

The following diagram illustrates a Breakpoint exception when the PE attempts to execute an instruction for which a breakpoint is set up:

 

Hardware breakpoints can be programmed to generate Breakpoint exceptions that are based on one of the following:

  • Unlinked instruction address match: Breakpoint matches when the PE executes from a virtual address with the same value as the DBGBVR register, and the current state of the PE matches the settings in DBGBCR.

    Unlinked Context ID match: Breakpoint matches when the PE executes an instruction while CONTEXTIDR_EL1, CONTEXTIDR_EL2 is the same as the DBGBVR register, and the current state of the PE matches the settings in DBGBCR. DBGBCR.BT defines whether CONTEXTIDR_EL1, CONTEXTIDR_EL2, or both, are used.

    These breakpoints route the control to the debugger when an application, an operating system, or an application within an operating system, is scheduled for execution.

    CONTEXTIDR_EL1 is programmed by the debugger with an application identifier.

    CONTEXTIDR_EL2 is programmed by the debugger with an operating system identifier.

  • Unlinked Virtual Machine ID (VMID) match: Breakpoint matches when the PE executes an instruction while VTTBR_EL2.VMID matches with the contents of the DBGBVR register, and the current state of the PE matches with the settings in DBGBCR.

    These breakpoints route the control to debugger when an operating system is scheduled for execution.

  • VTTBR_EL2.VMID is generally programmed by the hypervisor, which is responsible for launching the operating system. Debugger can use VTTBR_EL2.VMID value like an operating system identifier for the purpose of debug.
  • Unlinked Context ID and VMID match: Breakpoint matches when the PE executes an instruction while CONTEXTIDR_EL1 and VTTBR_EL2. VMID matches with the contents DBGBVR register, and the current state of the PE matches with the settings in DBGBCR.

    These breakpoints route the control to the debugger when an application within an operating system is scheduled for execution.

  • Linked Address matching breakpoints: Address matching breakpoints can be linked to Linked Context ID breakpoints, Linked VMID breakpoints, or Linked Context ID and VMID breakpoints.

    Linked Context ID breakpoints, Linked VMID breakpoints, and Linked Context ID and VMID breakpoints work in a similar way to the unlinked variants that we described previously, but they only work in conjunction with an address matching breakpoint. Linked breakpoints will not generate a breakpoint event on their own. However, they limit the context in which the address matching breakpoints can generate a breakpoint event.

    These breakpoints route the control to the debugger when the PE executes from an instruction address in:

  • An application: Address matching breakpoint linked to Linked Context ID breakpoint
  • An operating system: Address matching breakpoint linked to Linked VMID breakpoint or Linked Context ID breakpoint
  • An application within an operating system: Address matching breakpoint linked to Linked Context ID breakpoint or Linked Context ID & VMID breakpoint

    The Breakpoint Control Register, DBGBCR<n>_EL1 contains controls for the breakpoint, for example an enable control.

    The Breakpoint Value Register, DBGBVR<n>_EL1 holds the value that is used for breakpoint matching, that is one of the following:

  • An instruction virtual address
  • A Context ID
  • A VMID value
  • A concatenation of both a Context ID value and a VMID value

The Armv8-A architecture provides for 2-16 hardware breakpoints to be implemented. How many hardware breakpoints a particular implementation supports is implementation choice. Depending on the availability of the hardware breakpoint units, the same number of hardware breakpoints can be set up simultaneously on an implementation. The register ID_AA64DFR0_EL1. BRPs indicates how many breakpoint units are implemented.

Individual breakpoint units can be enabled or disabled by programming the E-bit of the individual debug breakpoint control register [DBGBCR<n>_El1.E].

Each breakpoint unit has a corresponding control register. Depending on how many breakpoints are implemented, the registers are numbered in line with this, so that:

  • DBGBCR0_EL1 and DBGBVR0_EL1 are for breakpoint 0.
  • DBGBCR1_EL1 and DBGBVR1_EL1 are for breakpoint 1.
  • DBGBCR2_EL1 and DBGBVR2_EL1 are for breakpoint 2.
  • DBGBCR<n>_EL1 and DBGBVR<n>_EL1 are for breakpoint n.
Watchpoint exception

A Watchpoint exception is generated when the PE accesses data from a particular address or address range. Hardware watchpoint registers can be programmed with the address of the application data. When the PE attempts to access data from the programmed address, it generates a Watchpoint exception. A watchpoint never generates a watchpoint debug event on an instruction fetch.

Here are the steps that are required to program a Watchpoint exception:

  1. The debugger programs the address of the data into the watchpoint value register, DBGWVR.
  2. The debugger enables the watchpoint in the watchpoint Control Register, DBGWCR, by setting the enable bit, DBGWCR.E, to generate a Watchpoint exception.

The following diagram illustrates a Watchpoint exception when a PE attempts to execute an instruction for which a watchpoint is set up:

 

DBGWCR has controls that allow the lower bits of DBGWVR to be masked in the address comparison. This means that a range of address can be watched.

A watchpoint can be:

  • Programmed to generate watchpoint debug events on read accesses only, on write accesses only, or on both types of access.
  • Linked to a linked context breakpoint, so that a watchpoint debug event is only generated if the PE is in a particular context when the address match occurs.

    The Armv8-A architecture provides for 2-16 hardware watchpoints to be implemented. How many hardware watchpoint units a particular implementation supports is implementation choice. Depending on the availability of the hardware watchpoint units, the same number of watchpoints can be set up simultaneously on an implementation.

    The ID_AA64DFR0_EL1.WRPs register shows how many watchpoint units are implemented.

    Individual watchpoint units can be enabled or disabled by programming the E-bit of the individual debug watchpoint control register [DBGWCR<n>_EL1.E].

     Each watchpoint unit has a corresponding control register. Depending on how many watchpoints are implemented, the registers are numbered in line with this, so that:

  • DBGWCR0_EL1 and DBGWVR0_EL1 are for watchpoint 0.
  • DBGWCR1_EL1 and DBGWVR1_EL1 are for watchpoint 1.
  • DBGWCR2_EL2 and DBGWVR2_EL1 are for watchpoint 2.

  • DBGWCR<n>_EL1 and DBGWVR<n>_EL1 are for watchpoint n.
Software Step exception

A software step event allows the debugger to take control of the program that is being debugged, which is also called the debuggee, after every individual instruction that is executed from the debuggee. When software step is enabled, a Software Step exception is generated whenever an instruction is retired from the debuggee.

Here are the steps that are required to program the Software Step exception:

  1. The debugger enables the Software Step exception by writing the MDSCR_EL1.SS to 1.
  2. The debugger sets the SPSR_ELx.SS bit to 1.
  3. The debugger programs the address of the instruction to be executed in the Exception Link Register (ELR).
  4. The debugger executes ERET.
  5. On ERET, the PE executes one instruction from the address that is programmed in the ELR, and takes the Single Step exception on the next instruction to ELd, returning control to the debugger.

A debugger can use software steps only when it is executing in an Exception level that is using AArch64. However, the instruction that is stepped might be executed in either Execution state, and therefore Software Step exceptions can be taken from either Execution state.

Software Step exceptions can be generated only when debug exceptions are enabled. If debug exceptions are disabled, software step is inactive.

Previous Next