Enabling and routing for debug exception

Enabling debug exceptions for self-hosted debugging

Breakpoint Instruction exceptions are always enabled and cannot be masked. For other exceptions, we can enable or disable individual exceptions as described in Debug exceptions. Here are the steps that are required to enable debug exceptions for self-hosted debugging:

  1. Clear the Operating System (OS) lock.
  2. Clear the OS double lock. This applies if the OS double lock is implemented.
  3. Clear MDCR_EL3.SDD. This applies if debugging Secure code.
  4. Set MDSCR_EL1.KDE to 1. This applies if debugging code that is executing at ELd in AArch64.
  5. If KDE is set, ensure that PSTATE.D is cleared to 0 for the code that is being debugged. You can achieve this using the MSR DAIFclr,#8 instruction, or by setting SPSR_ELd.D to 0 and executing an ERET instruction with the debuggee as the target.
  6. Set MDSCR_EL1.MDE / DBGDSCRint.MDBGen to 1. This enables debug events other than the Software Step event.
  7. Set MDCR_EL1.SS to 1. This enables the Software Step event.
    1. If SS bit is set, ensure that PSTATE.D is set to 1.
Routing for debug exceptions

In the Armv8-A Exception model, exceptions from EL0 cannot be handled at EL0. These exceptions should be routed to a higher Exception level. Debug exceptions from EL0 are also always routed to EL1 or EL2. This means that the debugger is installed at either EL1 or EL2.

If the debugger will be installed at EL1, set MDCR_EL2.TDE to 0. In this case, all debug exceptions are routed to EL1. If the debugger will be installed at EL2, set MDCR_EL2.TDE to 1. In this case, all debug exceptions are routed to EL2.

Previous Next