Estudio legal del mercado nacional e internacional

For details of debug events and their classification into Halting and Software debug events, see About Halting debug events on page 126 and Use of breakpoints and watchpoints by external debug on page 23.

On a debug event, the processor must do one of:

 enter Debug state

 pend the debug event, meaning it is taken later

 generate a debug exception

 ignore the debug event.

The behavior depends on both:

 Whether halting is allowed by the current state of the IMPLEMENTATION DEFINED authentication interface. See Halting allowed and halting prohibited, below.

 The type of debug event and the programming of the debug control registers. See:

— Halting debug events below for all Halting debug events

— Breakpoint and Watchpoint debug events on page 140 for Breakpoint and Watchpoint debug events

— Other Software debug events on page 140 for all other Software debug events.

This means the behavior can be UNPREDICTABLE if the conditions change. See Synchronization and Halting debug events on page 137.

Summary of actions from debug events on page 142 summarizes the possible outcomes of each type of debug event.

8.2.1 Halting allowed and halting prohibited

Halting can be either allowed or prohibited:

 Halting is always prohibited in Debug state.

 Halting is always prohibited when DoubleLockStatus() == TRUE (OS double-lock is locked).

 Halting is also controlled by the IMPLEMENTATION DEFINED authentication interface and is prohibited when either:

— the processor is in Non-secure state and ExternalInvasiveDebugEnabled() == FALSE

— the processor is in Secure state and ExternalSecureInvasiveDebugEnabled() == FALSE.

 Otherwise, halting is allowed.

See also:

 Pseudocode details of halting on debug events on page 143

 The Debug Authentication Interface on page 161.

8.2.2 Halting debug events

When a Halting debug event is generated it will cause entry to Debug state, if both:

 halting is allowed, see Halting allowed and halting prohibited above

 the Halting debug event is either:

— a Halt Instruction debug event and EDSCR.HDE == 1

Note: Halt Instruction is the only Halting debug event that relies on EDSCR.HDE == 1. This is to avoid entry to Debug state from malicious code. EDSCR.HDE is 0 on Cold reset.

Halting on Breakpoint and Watchpoint Software debug events is also controlled by EDSCR.HDE, see Breakpoint and Watchpoint debug events below.

EDSCR.HDE can be written by software through MDSCR_EL1 (AArch64) or DBGDSCRext (AArch32) when the OS lock is locked. Privileged code can use MDCR_EL3.TDOSA (if EL3 is using AArch64) and MDCR_EL2.TDOSA to trap writes to these registers.

— not a Halt Instruction debug event.

If a Halting debug event does not generate entry to Debug state then:

 if it is a Halt Instruction debug event, it generates an Undefined Instruction exception

 if it is an Exception Catch debug event or a Software Access debug event, it is ignored

 otherwise, it is pended, meaning:

— The pending Halting debug event is recorded in EDESR.

Note: This is a change from v7-A.

— The pending Halting debug event will be taken when halting becomes allowed. See Pending Halting debug events on page 138.

Pending Halting debug events are discarded by a Cold reset. The debugger can also force a pending event to be dropped. Summary of actions from debug events on page 142 summarizes the possible outcomes of each type of debug event.

8.2.3 Breakpoint and Watchpoint debug events

When Breakpoint or Watchpoint debug event is generated, it will generate an entry to Debug state if all of:

 EDSCR.HDE == 1 (Halting debug-mode is enabled for these events)

 halting is allowed, see Halting allowed and halting prohibited above

 OSLSR_EL1.OSLK == 0 (OS lock is unlocked).

The Address Mismatch breakpoint type is reserved if all of these conditions are met. See Legacy debug events on page 21.

If a Breakpoint or Watchpoint debug event generates entry to Debug state then it does not generate a debug exception.

However, if it does not generate entry to Debug state then it will either generate a debug exception or be ignored. See Debug Exception Model on page 52 and Note: halting and debug exceptions below.

8.2.4 Other Software debug events

Other Software debug events never generate an entry to Debug state; that is:

 Software Breakpoint Instruction debug events

 Software Step debug events

 Vector Catch debug events (see also Legacy debug events on page 21).

The behavior of these Software debug events is unchanged when EDSCR.HDE == 1, and will either generate a debug exception or be ignored. See Debug Exception Model on page 52 and also Note: halting and debug exceptions below.

8.2.5 Note: halting and debug exceptions

The behavior of Software debug events is changed compared to v7-A. In v7-A Software debug events other than BKPT Instruction debug events are ignored if DBGDSCRext.HDBGen is set to 1 but halting is prohibited.

This effectively means that self-hosted debug and external debug are mutually exclusive.

In v8-A, EDSCR.HDE is ignored when determining whether to generate a debug exception. The debug exception is suppressed only if Debug state is entered. This means that the exception model in Secure state is unaffected by the use of external debug in Non-secure state

Halting debug events never generate debug exceptions.

8.2.6 Debug state entry and debug event prioritization

The architecture does not define when asynchronous Halting debug events are taken, and therefore the prioritization of asynchronous debug events is IMPLEMENTATION DEFINED.

The following are synchronous Halting debug events:

 Halting Step debug event on page 127

 Halt Instruction debug event on page 133

 Exception Catch debug event on page 134

 Reset Catch debug event on page 136

 Software Access debug event on page 136.

Each of these is treated as a synchronous exception generated by an instruction or by the taking of an exception or reset. That is, they must be taken before any subsequent instructions are executed:

 Reset Catch debug events must be taken before the processor executes the instruction at the reset vector.

Note: Reset Catch and Exception Catch debug events may be generated asynchronously, in that they can happen as a result of an asynchronous exception. However, if halting is allowed after the asynchronous exception has been processed, the debug event is taken

synchronously.

 A Halting Step debug event is generated by the instruction after the stepped instruction. Therefore if the stepped instruction generates any other synchronous debug events, they will be taken first.

 OS Unlock Catch debug events are always pended and taken asynchronously.

Otherwise, the priority for synchronous debug events generating entry to Debug state, and relative exception priorities in brackets, is:

i. Reset Catch debug event

ii. Optionally Exception Catch debug event, see Prioritization of Exception Catch debug events on page 134

iii. Halting Step debug event

1. (Software Step debug event, see below)

1a. Optionally Exception Catch debug event, see Prioritization of Exception Catch debug events on page 134

2. (Misaligned PC) 3. (Instruction Abort)

4. Breakpoint debug event (or Address Matching Vector Catch debug event, see below) 5. (Illegal State)

6-19. Exception or traps resulting from the decode of the instruction, including:

14. Halt Instruction debug event 19a. Software Access debug event 20. (Stack Pointer Alignment)

21. (Data Aborts, other than Synchronous External Aborts not generated by a translation table walk) 22. Watchpoint debug event.

23. (Synchronous External Aborts not generated by a translation table walk)

Note: Some of these events are mutually exclusive; that is, they cannot happen concurrently within a single thread of execution.

For Reset Catch and Halting Step debug events, these priorities only apply when halting is allowed at the time where the event is generated, meaning the event is taken synchronously and not pended.

The prioritization of asynchronous Halting debug events, including pending Halting debug events taken asynchronously, is IMPLEMENTATION DEFINED, see Taking Halting debug events asynchronously on page 138.

For more information on the prioritization of exceptions, see Debug exception prioritization on page 60 and [v8Exception].

Debug state entry and Software Step

For the purposes of the behavior when Software Step is active, a debug event causing Debug state entry behaves like an exception taken to a higher EL than the debug exception target EL. That is:

 if the instruction being stepped generates a synchronous debug event that causes entry to Debug state, or an asynchronous debug event is taken without completing the step, Debug state is entered with DSPSR_EL0.SS set to 1

 a pending Halting debug event or an asynchronous debug event can be taken after the step has completed, in which case Debug state is entered with DSPSR_EL0.SS set to 0.

In addition:

 If both Halting and Software Step are active, they operate in parallel and can both become active-pending. In this case Halting Step has higher priority than Software Step, so Debug state is entered and DSPSR_EL0.SS set to 0.

 If Software Step completes with an exception trapped by an Exception Catch debug event, Debug state is entered with DSPSR_EL0.SS set to 0, as PSTATE.SS is set to 0 by the exception.

 If the processor is reset, PSTATE.SS is reset to 0. If any of Reset Catch, Exception Catch on the reset Exception level, or Halting Step are enabled, Debug state is entered with DSPSR_EL0.SS set to zero.

Breakpoint and Vector Catch debug events

An Address Matching Vector Catch debug event has the same priority as a Breakpoint debug event. See Prioritization of Vector Catch debug events on page 50.

The prioritization of Software debug events is unchanged even if the debug event generates entry to Debug state rather than a debug exception. This means that if a single instruction generates both an Address

Matching Vector Catch debug event and a Breakpoint debug event, EDSCR.HDE is set to 1, halting is allowed and the OS lock is unlocked, then it is CONSTRAINED UNPREDICTABLE whether the processor enters Debug state due to the Breakpoint debug event or takes an Address Matching Vector Catch exception.

An Exception Trapping Vector Catch debug event is tagged onto the end of the exception that generates it, and so isn’t considered part of the priority tree.

8.2.7 Imprecise entry to Debug state

Entry to Debug state is normally precise, meaning the processor cannot enter Debug state if it can neither complete nor abandon all currently executing instructions and leave the processor in a precise state.

A debugger can write 1 to EDRCR.CBRRQ to allow imprecise entry to Debug state. An External Debug Request debug event must be pending before writing 1 to this bit. Support for this feature is OPTIONAL and it is IMPLEMENTATION DEFINED when it is effective at forcing entry to Debug state.

The processor ignores writes to this bit if either:

 ExternalInvasiveDebugEnabled() == FALSE

 ExternalSecureInvasiveDebugEnabled() == FALSE and either:

— EL3 is not implemented and the processor is Secure

— EL3 is implemented.

Example: The debugger pends an External Debug Request debug event through the CTI to halt a program that has stopped responding. However, the memory system is not responding and a memory access instruction cannot complete, so Debug state cannot be entered precisely. The debugger writes 1 to EDRCR.CBRRQ. The processor cancels all outstanding memory accesses and enters Debug state. As some instructions may have not completed correctly, entry to Debug state is imprecise.

When Debug state is entered imprecisely all memory access instructions executed through the ITR have UNPREDICTABLE behavior. All registers are UNKNOWN, but might be useful for diagnostic purposes.

8.2.8 Summary of actions from debug events

Table 49 describes Software and Halting debug events. The columns have the following meanings:

Debug event type

Means the type of debug event, where:

Other Software means one of:

 Software Step debug event on page 39

 Software Breakpoint Instruction debug event on page 48

 Vector Catch debug event on page 49.

Other Halting means one of:

 Halting Step debug event on page 127

 External Debug Request debug event on page 135

 Reset Catch debug event on page 136

 OS Unlock Catch debug event on page 136.

Other debug events are referred to explicitly.

Auth Means halting is allowed by the IMPLEMENTATION DEFINED external authentication interface. The result of the pseudocode function:

In Secure state ExternalSecureInvasiveDebugEnabled(). In Non-secure state ExternalInvasiveDebugEnabled().

DLK Is the OS double-lock status, DoubleLockStatus().

OSLK Is the value of OSLSR_EL1.OSLK, that is, whether the OS lock is locked.

HDE Is the value of EDSCR.HDE, that is, whether Halting debug-mode is enabled for these events.

Debug event type Auth DLK OSLK HDE Behavior 96

Breakpoint or Watchpoint X TRUE X X Handled by exception model (ignored) 8

Debug event type Auth DLK OSLK HDE Behavior 96 X FALSE 1 X Handled by exception model (ignored) 4

FALSE FALSE 0 X Handled by exception model 2

TRUE FALSE 0 0 Handled by exception model 1

TRUE FALSE 0 1 Enter Debug state 1

Other Software X X X X Handled by exception model 16

Halt Instruction FALSE X X X UNDEFINED 8

TRUE TRUE X X UNDEFINED 4

TRUE FALSE X 0 UNDEFINED 2

TRUE FALSE X 1 Enter Debug state 2

Exception Catch FALSE X X X Ignore 8

TRUE TRUE X X Ignore 4

TRUE FALSE X X Enter Debug state 4

Software Access FALSE X X X Ignore 8

TRUE TRUE X X Ignore 4

TRUE FALSE 1 X Ignore 2

TRUE FALSE 0 X Enter Debug state 2

Other Halting FALSE X X X Pend debug event 8

TRUE TRUE X X Pend debug event 4

TRUE FALSE X X Enter Debug state 4

Table 49: Authentication for external debug

8.2.9 Pseudocode details of halting on debug events

// Function 39: Halted // ===================

boolean Halted()

return !(EDSCR.STATUS IN {‘000001’, ‘000010’}); // Halted // Function 40: Restarting

// =======================

boolean Restarting()

return EDSCR.STATUS == ‘000001’; // Restarting

// Function 41: HaltOnBreakpointOrWatchpoint // =========================================

boolean HaltOnBreakpointOrWatchpoint()

// Returns TRUE if the Breakpoint and Watchpoint debug events should be considered for Debug // state entry, FALSE if they should be considered for a debug exception.

return EDSCR.HDE == '1' && OSLSR_EL1.OSLK == ‘0’ && HaltingAllowed();

// Function 42: HaltingAllowed // ===========================

boolean HaltingAllowed()

// Returns TRUE if halting is currently allowed, FALSE if halting is prohibited.

if Halted() || DoubleLockStatus() then return FALSE;

elsif IsSecure() then return ExternalSecureInvasiveDebugEnabled();

else return ExternalInvasiveDebugEnabled();

In document Elaboró Revisó Aprobó RESUMEN TRABAJO DE GRADO (página 46-50)