Resultados de la encuesta

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();

8.3 Entering Debug state

Rationale: see Entering Debug state on page 265.

On entry to Debug state the PC and PSTATE are saved in DLR_EL0 and DSPSR_EL0. The processor remains in the mode and security state from which Debug state was entered. See Debug Link Register, DLR_EL0 and Debug Saved Processor Status Register, DSPSR_EL0 starting on page 221.

If EDRCR.CBRRQ is set to 0, entry to Debug state is precise. If EDRCR.CBRRQ has been set to 1 then entry to Debug state is permitted to be imprecise.

If the Debug state entry is due to a Watchpoint debug event, the address of the access that generated the Watchpoint debug event is recorded in the EDWAR.

Other than the effect on PSTATE and EDSCR, entry to Debug state is not a context synchronization operation. The effects of entry to Debug state on PSTATE and EDSCR are synchronized.

8.3.1 Entering Debug state from AArch32 state

When Debug state is entered from AArch32 state, the processor remains in AArch32 state. In AArch32 Debug state the processor executes T32 instructions, regardless of the values the PSTATE.{J, T} bits held before entering Debug state.

To allow the debugger to determine the execution state of the processor, the current execution state for all four Exception levels can be read from EDSCR.RW.

Endianness (PSTATE.E) is unchanged on entry to Debug state.

Notes:

— In EL1 using AArch32 the current endianness state can differ from that indicated by SCTLR.EE.

— In EL2 using AArch32 the current endianness state can differ from that indicated by HSCTLR.EE.

— On entry to Debug state from AArch32 state, PSTATE.SS is copied to DSPSR_EL0.SS, even though the processor remains in AArch32 state.

See also Effect of entering Debug state on PSTATE below.

8.3.2 Effect of entering Debug state on DLR_EL0 and DSPSR_EL0

DLR_EL0 is set to the preferred restart address for the debug event, and depends on the event type.

PSTATE is saved in DSPSR_EL0. For entry to Debug state from AArch32, the value saved in DSPSR_EL0.IT is always correct for the preferred restart address.

For synchronous Halting debug events

The preferred restart address is the address of the instruction that generated the debug event.

For asynchronous Halting debug events, including pending Halting debug events taken asynchronously

The preferred restart address is the address of the first instruction that should be executed on exit from Debug state (i.e. just like the ELR value delivered to an interrupt handler).

This means that:

 For Breakpoint and Watchpoint debug events, DLR_EL0 is set to the same value as the preferred return address for a Breakpoint or Watchpoint exception. See Preferred return address on page 59.

 For Halt Instruction debug events DLR_EL0 is set to the address of the HLT instruction and DSPSR_EL0.IT is correct for the HLT instruction.

 For Software Access debug events DLR_EL0 is set to the address of the accessing instruction and DSPSR_EL0.IT is correct for this instruction.

 For Halting Step debug events taken synchronously, DLR_EL0 and DSPSR_EL0 are set as the ELR and SPSR would be set for a Software Step exception. This is usually the address of and PSTATE for the instruction after the one that was stepped.

 For Exception Catch debug events:

— Generated on an exception taken to a trapped EL, DLR_EL0 is set to the address of the exception vector the processor would have started fetching from, although this might be UNKNOWN ifthe VBAR for the EL has never been initialized. DSPSR_EL0 records the value of PSTATE after taking the exception. The exception catch occurs after the ELR and SPSR for the exception are set, and the debugger can use these registers to determine from where the exception was taken.

— Generated on taking an exception return to a trapped EL, DLR_EL0 is set to the target address of the exception return and DSPSR_EL0 records the value of PSTATE after the exception return.

 For Reset Catch debug events and Exception Catch debug events generated on reset to a trapped EL, DLR_EL0 is set to the reset address and DSPSR_EL0 records the reset value of PSTATE.

 For pending Halting debug events and External Debug Request debug events, DLR_EL0 is set the address of the first instruction that should be executed on exit from Debug state and DSPSR_EL0.IT is correct for this instruction.

Normally DLR_EL0 is aligned according to the instruction set state indicated in DSPSR_EL0. However, a debug event might be taken at a point where the PC was not aligned.

8.3.3 Effect of entering Debug state on system registers, the Event Register, and exclusive monitors

Entering Debug state has no effect on system registers other than DLR_EL0 and DSPSR_EL0. In particular, ESRs, FARs, FSRs, etc. are not updated on entering Debug state. SCR_EL3.NS / SCR.NS is unchanged, even when entering from EL3.

Entering Debug state has no architecturally-defined effect on the Event Register and exclusive monitors.

Note: Entry to Debug state might set the Event Register and/or clear the exclusive monitors on entry to Debug state, but this is not required and debuggers must not rely on any implementation-specific behavior.

Unless otherwise described in this manual, instructions executed in Debug state have their architecturally-defined effects on the system registers, Event Register and exclusive monitors.

8.3.4 Effect of entering Debug state on PSTATE

As described in Entering Debug state above and Entering Debug state from AArch32 state above, PSTATE.{E, M, nRW, EL, SP} are unchanged on entry to Debug state.

PSTATE.IL is cleared to 0 on entry to Debug state, after being saved in DSPSR_EL0.

The other PSTATE fields are ignored and not observable in Debug state and:

 the PSTATE.{N, Z, C, V, Q, GE} fields are notionally unchanged

 the PSTATE.{IT, J, T, SS, D, A, I, F} fields are notionally set UNKNOWN values, after being saved in DSPSR_EL0.

For more information see Process state (PSTATE) in Debug state on page 146.

8.3.5 Entering Debug state during loads and stores

Debug state can be entered during instructions which perform a sequence of memory accesses, as opposed to a single single-copy atomic access, due to Watchpoint debug event. The effect of entering Debug state on such an instruction is the same as taking a Data Abort exception during such an instruction.

In addition, when executing in AArch64, Debug state can be entered during instructions which perform a sequence of memory accesses due to an External Debug Request debug event. The effect of entering Debug state on such an instruction is the same as taking an interrupt exception during such an instruction.

This applies for all memory types.

8.3.6 Pseudocode details of entry to Debug state

// DebugHalt // =========

// Reason codes for entry to Debug state

constant bits(6) DebugHalt_Breakpoint = '000111';

constant bits(6) DebugHalt_EDBGRQ = '010011';

constant bits(6) DebugHalt_Step_Normal = '011011';

constant bits(6) DebugHalt_Step_Exclusive = '011111';

constant bits(6) DebugHalt_OSUnlockCatch = '100011';

constant bits(6) DebugHalt_ResetCatch = '100111';

constant bits(6) DebugHalt_Watchpoint = '101011';

constant bits(6) DebugHalt_HaltInstruction = '101111';

constant bits(6) DebugHalt_SoftwareAccess = '110011';

constant bits(6) DebugHalt_ExceptionCatch = '110111';

constant bits(6) DebugHalt_Step_NoSyndrome = '111011';

// Function 43: Halt // =================

Halt(bits(6) reason)

CTI_SignalEvent(CrossTriggerIn_CrossHalt); // Trigger other cores to halt DLR_EL0 = ThisInstrAddr();

DSPSR_EL0 = GetSPSRFromPSTATE();

DSPSR_EL0.SS = PSTATE.SS; // Always save PSTATE.SS

EDSCR.ITE = '1'; EDSCR.ITO = '0';

if IsSecure() then

EDSCR.SDD = '0'; // If entered in Secure state, allow debug elsif HaveEL(EL3) then

EDSCR.SDD = (if ExternalSecureInvasiveDebugEnabled() then '0' else '1');

else

assert EDSCR.SDD == '1'; // Otherwise EDSCR.SDD is RES1 EDSCR.MA = '0';

// PSTATE.{SS,D,A,I,F} are not observable and ignored in Debug state, so behave as if

// UNKNOWN. PSTATE.{N,Z,C,V,Q,GE} are also not observable, but since these are not changed on // exception entry, this function also leaves them unchanged. PSTATE.{E,M,nRW,EL,SP} are // unchanged. PSTATE.IL is set to 0.

if UsingAArch32() then

PSTATE.<SS,A,I,F> = bits(4) UNKNOWN;

// In AArch32, all instructions are T32 and unconditional.

PSTATE.IT = '00000000'; PSTATE.<J,T> = '01';

else

PSTATE.<SS,D,A,I,F> = bits(5) UNKNOWN;

PSTATE.IL = '0';

StopInstructionPrefetchAndEnableITR();

EDSCR.STATUS = reason; // Signal entered Debug state

UpdateEDSCRFields(); // Update EDSCR processor state flags.

return;

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