ARM Processor Division
Architecture Group
Document number: PRD03-PRDC-010486 59.0 Date of Issue: 7 September, 2015
Copyright © 2009-2015 ARM Limited
Contents
ABOUT THIS DOCUMENT ... 14
PART A: BACKGROUND AND REQUIREMENTS ... 15
1
READ ME FIRST!... 15
1.1 Document status ... 15
1.1.1 Differences between this document and DDI0487A ... 15
1.2 Required reading ... 15
2
INTRODUCTION TO ARMV8 DEBUG ... 16
2.1 Introduction ... 16
2.2 Overview ... 16
2.2.1 The debug model ... 16
2.2.2 Basic feature set ... 18
2.2.3 Key differences from v7-A ... 18
2.2.4 Debug register interfaces ... 19
2.2.5 Concurrent use of debug by multiple agents, and ownership of debug resources ... 19
2.2.6 Multi-processing ... 20
2.2.7 Performance monitors ... 20
2.2.8 Other areas of debug within ARM architectures... 20
2.3 Compatibility for v7-A (32-bit) software ... 20
PART B: ARMV8 SELF-HOSTED DEBUG ... 21
3
SOFTWARE DEBUG EVENTS ... 21
3.1 About Software debug events ... 21
3.1.1 Legacy debug events ... 21
3.1.2 Use of breakpoints and watchpoints by external debug ... 23
3.2 Breakpoint debug event ... 23
3.2.1 Programming Breakpoint debug events ... 23
3.2.2 Breakpoint types ... 23
3.2.3 Address breakpoints ... 24
3.2.4 Context breakpoints and linking ... 25
3.2.5 Processor state matching ... 25
3.2.6 Address Mismatch breakpoints ... 27
3.2.7 Breakpoints on the first instruction in a T32 IT block ... 27
3.2.8 Constraints on programming Breakpoint debug events ... 28
3.2.9 Pseudocode details of Breakpoint debug events ... 31
3.3 Watchpoint debug event ... 33
3.3.1 Programming Watchpoint debug events ... 33
3.3.2 Watchpoint types ... 34
3.3.3 Address watchpoints ... 34
3.3.4 Processor state matching ... 34
3.3.5 Effect of watchpoints ... 36
3.3.6 Watchpoints and Store Exclusive operations ... 36
3.3.8 Determining the location of a watchpointed access ... 36
3.3.9 Constraints on programming Watchpoint debug events ... 37
3.3.10 Pseudocode details of Watchpoint debug events ... 38
3.4 Software Step debug event ... 39
3.4.1 Overview of Software Step ... 39
3.4.2 Detailed description of the Software Step state machine ... 40
3.4.3 Examples of Software Step ... 45
3.4.4 Software Step of T32 IT instructions ... 45
3.4.5 Syndrome information on a Software Step exception ... 45
3.4.6 Pseudocode details of Software Step debug events ... 46
3.5 Software Breakpoint Instruction debug event ... 48
3.5.1 Programming Software Breakpoint Instruction debug events ... 48
3.5.2 Software breakpoint instructions as the first instruction in a T32 IT block ... 48
3.5.3 Pseudocode details of Software Breakpoint Instruction debug events ... 49
3.6 Vector Catch debug event ... 49
3.6.1 Programming Vector Catch debug events ... 49
3.6.2 Address Matching and Exception Trapping forms ... 49
3.6.3 Vector Catch debug events and exception routing ... 50
3.6.4 Prioritization of Vector Catch debug events ... 50
3.6.5 Constraints on programming Vector Catch debug events ... 50
3.6.6 Pseudocode details of Vector Catch debug events ... 51
3.7 Synchronization and Software debug events ... 51
3.7.1 Mode and state changes without explicit synchronization ... 52
4
DEBUG EXCEPTION MODEL ... 52
4.1 Controlling debug exceptions ... 52
4.1.1 Routing debug exceptions ... 52
4.1.2 Enabling debug exceptions other than Software Breakpoint Instruction routed to an EL using AArch64 53 4.1.3 Enabling debug exceptions other than Software Breakpoint Instruction routed to an EL using AArch32 54 4.1.4 Software Breakpoint Instruction exceptions ... 55
4.1.5 Pseudocode details of routing debug exceptions ... 56
4.2 Debug exception behavior ... 58
4.2.1 Effect of taking debug exception to an EL using AArch64 on system registers ... 58
4.2.2 Effect of taking debug exception to an EL using AArch32 on system registers ... 59
4.2.3 Preferred return address ... 59
4.2.4 Debug exception prioritization ... 60
4.2.5 Pseudocode details of debug exceptions ... 60
5
DEBUG SYSTEM REGISTERS ... 61
5.1 Note on register naming ... 61
5.2 Register widths ... 61
5.3 Debug system register maps... 61
5.4 Accessing debug system registers ... 63
5.5 Synchronization of changes to debug system registers ... 66
5.7 Debug system register resets ... 66
5.8 Relationship between AArch32 and AArch64 debug system registers ... 68
5.9 Self-hosted debug system register definitions ... 69
5.9.1 AArch64 Debug Feature Register, ID_AA64DFR0_EL1 ... 69
5.9.2 Breakpoint Value Registers, DBGBVRn_EL1 ... 70
5.9.3 Breakpoint Control Registers, DBGBCRn_EL1 ... 71
5.9.4 Watchpoint Value Registers, DBGWVRn_EL1... 74
5.9.5 Watchpoint Control Registers, DBGWCRn_EL1 ... 75
5.9.6 Monitor Debug System Control Register, MDSCR_EL1 ... 77
5.9.7 Monitor Debug Configuration Register, MDCR_EL2 ... 80
5.9.8 Monitor Debug Configuration Register, MDCR_EL3 ... 81
5.9.9 Debug Power Control Register, DBGPRCR_EL1 ... 83
5.9.10 Debug ROM Address Register, MDRAR_EL1 ... 83
5.9.11 Data Transfer Registers, DBGDTRTX_EL0, DBGDTRRX_EL0 and DBGDTR_EL0 ... 84
5.9.12 Debug Comms Channel Status Register, MDCCSR_EL0 ... 85
5.9.13 Debug Comms Channel Interrupt Enable register, MDCCINT_EL1 ... 86
5.9.14 Authentication Status register, DBGAUTHSTATUS_EL1 ... 86
5.9.15 Claim Tag registers, DBGCLAIMSET_EL1 and DBGCLAIMCLR_EL1 ... 87
5.10 OS Save and Restore registers... 88
5.10.1 OS Lock Access Register, OSLAR_EL1 ... 88
5.10.2 OS Lock Status Register, OSLSR_EL1 ... 88
5.10.3 OS Double Lock Register, OSDLR_EL1 ... 89
5.10.4 OS Lock Exception Catch Control Register, OSECCR_EL1 ... 89
5.10.5 OS Lock Data Transfer Registers, OSDTRRX_EL1 and OSDTRTX_EL1 ... 90
5.11 AArch32 debug system register definitions ... 90
5.11.1 Debug ID Register, DBGDIDR ... 90
5.11.2 Debug Self Address Register, DBGDSAR ... 91
5.11.3 Debug Device ID registers, DBGDEVID{n} ... 91
5.11.4 Debug Feature Register, ID_DFR0_EL1 ... 92
5.11.5 Debug Status and Control Register, DBGDSCR, summary ... 93
5.11.6 Secure Debug Configuration Register, SDCR ... 93
5.11.7 Secure Debug Enable Register, SDER32_EL3 ... 94
5.11.8 Vector Catch Register, DBGVCR32_EL2 ... 95
5.12 IMPLEMENTATION DEFINED debug registers ... 96
PART C: PERFORMANCE MONITORS EXTENSION ... 97
6
PERFORMANCE MONITORS ... 97
6.1 Introduction ... 97
6.2 Updates to the Performance Monitors extension for v8-A ... 97
6.3 Attributability... 98
6.3.1 Performance Monitors and security ... 99
6.3.2 Filtering by Exception level and state ... 100
6.3.3 Performance Monitors and Debug state ... 100
6.4 Accuracy of the Performance Monitors ... 100
6.4.1 Non-invasive behavior ... 101
6.4.2 A reasonable degree of inaccuracy ... 101
6.5 Performance Monitors and virtualization ... 101
6.5.2 CCNT cycle counter ... 102
6.6 Interrupt-driven use of Performance Monitors ... 102
6.7 Performance Monitors registers ... 103
6.7.1 Performance Monitors system register map ... 103
6.7.2 Accessing Performance Monitors registers ... 104
6.7.3 Performance Monitors system register resets ... 105
6.7.4 Relationship between AArch32 and AArch64 Performance Monitors registers ... 106
6.8 Performance Monitors register definitions ... 106
6.8.1 Performance Monitors Control Register, PMCR_EL0 ... 106
6.8.2 Performance Monitors Cycle Counter, PMCCNTR_EL0 ... 108
6.8.3 Selected Event Counter Register, PMXEVCNTR_EL0 ... 109
6.8.4 Event Counter Register, PMEVCNTRn_EL0 ... 109
6.8.5 Selected Event Type and Filter Register, PMXEVTYPER_EL0 ... 109
6.8.6 Event Type and Cycle Counter Filter Registers, PMEVTYPERn_EL0 and PMCCFILTR_EL0 .... 110
6.8.7 User Enable Register, PMUSERENR_EL0 ... 112
6.8.8 Count Enable Set and Clear Registers, PMCNTENSET_EL0 and PMCNTENCLR_EL0 ... 113
6.8.9 Interrupt Enable Set and Clear Registers, PMINTENSET_EL1 and PMINTENCLR_EL1 ... 113
6.8.10 Overflow Flag Status Set and Clear Registers, PMOVSSET_EL0 and PMOVSCLR_EL0 ... 114
6.8.11 Software Increment Register, PMSWINC_EL0 ... 115
6.8.12 Common Event Identification registers, PMCEID0_EL0 and PMCEID1_EL0 ... 115
6.9 Pseudocode details of Performance Monitors ... 116
6.10 Configuring Performance Monitors registers ... 117
6.10.1 MDCR_EL2.HPMN ... 117
6.10.2 PMSELR_EL0.SEL ... 118
6.10.3 PMEVCNTRn_EL0 and PMEVTYPERn_EL0 (direct access) ... 118
6.10.4 PMEVTYPERn_EL0[31:26] and PMCCFILTR_EL0[31:26] ... 119
6.10.5 PMEVTYPERn_EL0.evtCount ... 119
6.11 Events ... 119
6.11.1 Required events ... 119
6.11.2 Common architectural and microarchitectural events ... 120
6.11.3 Recommendations for additional IMPLEMENTATION DEFINED events ... 124
6.11.4 “Speculatively executed” events ... 124
6.12 External access to the Performance Monitors ... 125
PART D: ARMV8 EXTERNAL DEBUG ... 126
7
HALTING DEBUG EVENTS ... 126
7.1 About Halting debug events ... 126
7.2 Halting Step debug event ... 127
7.2.1 Overview of Halting Step ... 127
7.2.2 Detailed description of the Halting Step state machine ... 128
7.2.3 Synchronization and the Halting Step state machine ... 131
7.2.4 Examples of Halting Step ... 131
7.2.5 Halting Step of T32 IT instructions ... 131
7.2.6 Syndrome information on Halting Step ... 131
7.2.7 Pseudocode details of Halting Step debug events ... 132
7.3 Halt Instruction debug event ... 133
7.3.1 HLT instructions as the first instruction in a T32 IT block ... 133
7.4 Exception Catch debug event ... 134
7.4.1 Prioritization of Exception Catch debug events ... 134
7.4.2 UNPREDICTABLE generation of Exception Catch debug events ... 135
7.4.3 Pseudocode details of Exception Catch debug events ... 135
7.5 External Debug Request debug event ... 135
7.5.1 Pseudocode details of External Debug Request debug events ... 135
7.6 OS Unlock Catch debug event ... 136
7.6.1 Pseudocode details of OS Unlock Catch debug events ... 136
7.7 Reset Catch debug event ... 136
7.7.1 Pseudocode details of Reset Catch debug events ... 136
7.8 Software Access debug event ... 136
7.8.1 Pseudocode details of Software Access debug events ... 137
7.9 Synchronization and Halting debug events ... 137
7.10 WFI and WFE wake-up events ... 138
8
DEBUG STATE ... 138
8.1 Introduction ... 138
8.2 Halting the processor on debug events ... 138
8.2.1 Halting allowed and halting prohibited ... 139
8.2.2 Halting debug events ... 139
8.2.3 Breakpoint and Watchpoint debug events... 140
8.2.4 Other Software debug events ... 140
8.2.5 Note: halting and debug exceptions ... 140
8.2.6 Debug state entry and debug event prioritization ... 140
8.2.7 Imprecise entry to Debug state ... 142
8.2.8 Summary of actions from debug events ... 142
8.2.9 Pseudocode details of halting on debug events ... 143
8.3 Entering Debug state ... 143
8.3.1 Entering Debug state from AArch32 state ... 144
8.3.2 Effect of entering Debug state on DLR_EL0 and DSPSR_EL0 ... 144
8.3.3 Effect of entering Debug state on system registers, the Event Register, and exclusive monitors 145 8.3.4 Effect of entering Debug state on PSTATE ... 145
8.3.5 Entering Debug state during loads and stores ... 145
8.3.6 Pseudocode details of entry to Debug state... 145
8.4 Behavior in Debug state ... 146
8.4.1 Process state (PSTATE) in Debug state ... 146
8.4.2 Executing instructions in Debug state ... 146
8.4.3 Decode tables ... 150
8.4.4 Security in Debug state ... 153
8.4.5 Privilege in Debug state ... 153
8.4.6 Debug state instructions ... 154
8.4.7 Exceptions in Debug state ... 156
8.4.8 Accessing registers in Debug state ... 159
8.4.9 Accessing memory in Debug state ... 159
8.5 Exiting Debug state ... 159
8.5.1 Pseudocode details of Debug state exit ... 160
10
THE DEBUG COMMUNICATIONS CHANNEL (DCC) AND INSTRUCTION
TRANSFER REGISTER (ITR) ... 161
10.1 Introduction ... 161
10.2 DCC and ITR registers ... 161
10.2.1 Save and restore ... 163
10.3 DCC and ITR access modes... 163
10.3.1 Normal access mode ... 164
10.3.2 Memory access mode ... 164
10.3.3 Memory-mapped accesses to the DCC and ITR... 166
10.4 Flow-control of the DCC and ITR registers ... 166
10.4.1 Ready flags ... 166
10.4.2 Buffering writes to EDITR ... 167
10.4.3 Overrun and underrun flags... 167
10.4.4 Cumulative error flag ... 168
10.5 Synchronization of DCC and ITR accesses ... 168
10.5.1 Summary of system register accesses to the DCC ... 169
10.5.2 DCC accesses in Non-debug state ... 169
10.5.3 Synchronization of DCC interrupt request signals ... 171
10.5.4 DCC and ITR accesses in Debug state ... 171
10.6 Interrupt-driven use of DCC ... 172
10.7 Pseudocode details of the DCC and ITR registers ... 172
11
DEBUG OVER POWER-DOWN... 174
11.1 Power states ... 175
11.1.1 Core power domain states... 175
11.1.2 Emulating low-power states... 176
11.1.3 Pseudocode details of the Core power domain... 177
11.2 Debug OS save and restore sequences ... 177
11.2.1 Behavior when the OS lock is locked ... 177
11.2.2 Behavior on unlocking the OS lock ... 177
11.2.3 Behavior when the OS double-lock is locked ... 178
11.2.4 Pseudocode details of the OS lock and OS double-lock ... 179
12
EMBEDDED CROSS-TRIGGER ... 179
12.1 Overview of the Embedded Cross-Trigger (ECT) ... 179
12.2 Basic operation ... 179
12.2.1 Multicycle events ... 181
12.3 Cross-trigger interface programmers’ model ... 181
12.3.1 Description and allocation of CTI triggers ... 182
12.3.2 CTI registers programmers’ model ... 184
12.3.3 CTI reset ... 184
12.3.4 CTI authentication ... 184
12.4 Implementation with a CoreSight CTI ... 185
13
SAMPLE-BASED PROFILING EXTENSION ... 185
13.1 Accuracy of sampling ... 185
13.2 Sample-based Profiling and security ... 186
13.3 Pseudocode details of Sample-based Profiling ... 186
14
TRACE EXTENSION ... 187
14.1 Trace and security ... 187
15
CACHE AND TLB VISIBILITY ... 187
16
EXTERNAL DEBUG REGISTERS ... 188
16.1 Register resets and power domains ... 188
16.1.1 Example reset implementation ... 189
16.1.2 External debug interface accesses to registers in reset ... 189
16.2 Multi-threaded implementations ... 189
16.3 Synchronization of changes to external debug registers ... 190
16.3.1 Examples of synchronization of changes to external debug registers ... 191
16.4 Supported access sizes ... 193
16.5 Memory-mapped accesses to the external debug interface ... 193
16.5.1.1 Register access permissions for memory-mapped accesses ... 194
16.5.2 Synchronization of memory-mapped accesses to external debug registers ... 194
16.5.3 Access sizes for memory-mapped accesses ... 194
16.6 External debug interface register access permissions ... 195
16.6.1 External debug over power-down and locks ... 195
16.6.2 External access disabled ... 195
16.6.3 Behavior of a not permitted access ... 196
16.6.4 External debug interface register access permissions summary ... 197
16.6.5 IMPLEMENTATION DEFINED registers ... 197
16.6.6 OPTIONAL CoreSight management registers ... 197
16.6.7 Reserved and unallocated registers ... 197
16.7 Debug external registers ... 198
16.7.1 Debug external registers map ... 198
16.7.2 Accessing external debug registers ... 199
16.7.3 External debug register resets ... 201
16.7.4 Relationship between external debug and system registers ... 202
16.8 External debug register definitions ... 203
16.8.1 External Debug Status and Control Register, EDSCR ... 203
16.8.2 External Debug Instruction Transfer Register, EDITR ... 208
16.8.3 External Debug Watchpoint Address Register, EDWAR ... 208
16.8.4 External Debug Power/Reset Control Register, EDPRCR ... 208
16.8.5 External Debug Processor Status Register, EDPRSR ... 209
16.8.6 External Debug Reserve Control Register, EDRCR ... 213
16.8.7 External Debug Auxiliary Control Register, EDACR ... 214
16.8.8 External Debug Exception Catch Control Register, EDECCR ... 214
16.8.9 External Debug Execution Control Register, EDECR ... 215
16.8.11 External Debug Program Counter Sample Registers, EDPCSRhi and EDPCSRlo ... 216
16.8.12 External Debug Context ID Sample Register, EDCIDSR ... 217
16.8.13 External Debug Virtual Context Sample Register, EDVIDSR ... 217
16.8.14 Main ID register, MIDR_EL1 ... 218
16.8.15 External Debug Processor Feature Register, EDPFR ... 218
16.8.16 External Debug Feature Register, EDDFR ... 219
16.8.17 Reserved ID registers ... 219
16.8.18 External Debug AArch32 Processor Feature Register, EDAA32PFR ... 220
16.8.19 Device ID registers, EDDEVID{n} ... 220
16.9 External debug system registers... 221
16.9.1 External debug system register map ... 221
16.9.2 Accessing external debug system registers ... 221
16.9.3 External debug system register resets ... 221
16.9.4 Relationship between AArch32 and AArch64 external debug system registers ... 221
16.10 External debug system register definitions ... 221
16.10.1 Debug Link Register, DLR_EL0 ... 221
16.10.2 Debug Saved Processor Status Register, DSPSR_EL0 ... 222
16.11 Performance Monitors external registers ... 222
16.11.1 Performance Monitors external registers map ... 222
16.11.2 Accessing Performance Monitors external registers ... 223
16.11.3 Performance Monitors external register resets ... 223
16.12 Performance Monitors external register definitions... 223
16.12.1 Performance Monitors Configuration Register, PMCFGR ... 223
16.13 Cross-trigger interface registers ... 224
16.13.1 Cross-trigger interface registers map ... 224
16.13.2 Accessing cross-trigger interface registers ... 225
16.13.3 Cross-trigger interface register resets ... 226
16.14 Cross-trigger interface register definitions ... 226
16.14.1 Control register, CTICONTROL ... 226
16.14.2 Output Trigger Acknowledge register, CTIINTACK ... 227
16.14.3 Application Trigger Set register, CTIAPPSET ... 227
16.14.4 Application Trigger Clear register, CTIAPPCLEAR ... 228
16.14.5 Application Pulse register, CTIAPPPULSE ... 228
16.14.6 Input Trigger to Output Channel Enable registers, CTIINENn ... 228
16.14.7 Input Channel to Output Trigger Enable registers, CTIOUTENn ... 229
16.14.8 Trigger In Status register, CTITRIGINSTATUS ... 229
16.14.9 Trigger Out Status register, CTITRIGOUTSTATUS ... 229
16.14.10 Channel In Status register, CTICHINSTATUS ... 230
16.14.11 Channel Out Status register, CTICHOUTSTATUS ... 230
16.14.12 Channel Gate Enable register, CTIGATE ... 230
16.14.13 External Control register, ASICCTL ... 231
16.14.14 Device ID registers, CTIDEVID{n} ... 231
16.15 Management registers and CoreSight compliance ... 232
16.15.1 External debug interface management register map ... 232
16.15.2 Accessing management registers ... 233
16.15.3 Management register resets ... 234
16.16 Management register definitions ... 234
16.16.1 Integration Mode Control register, ITCTRL... 234
16.16.2 Claim Tag registers, CLAIMSET and CLAIMCLR ... 235
16.16.3 Lock Access and Lock Status Registers, LAR and LSR ... 235
16.16.4 Device Affinity registers, DEVAFFn ... 236
16.16.6 Device Architecture register, DEVARCH ... 237
16.16.7 Device Type register, DEVTYPE ... 238
16.16.8 Peripheral and Component Identification Registers, PIDRn and CIDRn ... 239
PART E: APPENDICES ... 241
17
APPENDIX: USING ARMV8 SELF-HOSTED DEBUG ... 241
17.1 Enabling self-hosted debug ... 241
17.1.1 Kernel debugging ... 241
17.2 Using Breakpoint and Watchpoint exceptions ... 241
17.2.1 Enabling Breakpoint exceptions ... 241
17.2.2 Enabling Watchpoint exceptions ... 242
17.2.3 Programming breakpoints and watchpoints according to the debugger’s view ... 242
17.2.4 Determining the location of a watchpointed access ... 243
17.3 Using Software Step exceptions ... 243
17.3.1 Software Step and exception handlers ... 243
17.3.2 Software Step and Misaligned PC exceptions ... 244
17.3.3 Software Step of code using exclusive monitors ... 244
17.3.4 Hypervisor emulation of a guest operating system using step ... 244
18
APPENDIX: USING ARMV8 EXTERNAL DEBUG ... 245
18.1 Enabling external debug ... 245
18.2 Using Breakpoint and Watchpoints debug events ... 245
18.2.1 Enabling Breakpoint debug events ... 245
18.2.2 Enabling Watchpoint debug events ... 245
18.2.3 Access to breakpoint and watchpoint registers ... 245
18.3 Using Halting Step debug events ... 245
18.3.1 Disabling interrupts whilst stepping ... 246
18.3.2 Halting Step of code using exclusive monitors ... 246
18.4 Other halting debug events ... 246
18.4.1 Using the Exception Catch debug event ... 246
18.4.2 Using the OS Unlock Catch debug event ... 246
18.5 Debug state ... 247
18.5.1 Forcing entry to Debug state ... 247
18.5.2 Accessing registers in Debug state ... 247
18.5.3 Accessing memory in Debug state ... 249
18.6 Debug comms channel ... 251
18.6.1 Accessing DCC from Software in Non-debug state ... 251
18.6.2 Using the DCC to access 64-bit data ... 251
18.7 Debug over power-down ... 252
18.7.1 Debug registers to save over power-down ... 252
18.7.2 OS save sequence ... 253
18.7.3 OS restore sequence ... 253
18.7.4 Example OS Save and Restore sequences ... 253
18.7.5 Recommended use of CLAIM tags for negotiating debug over power-down ... 255
18.8 Using the Cross Trigger Interface ... 257
18.8.2 Example 2: halting all processors in a group when any one processor halts ... 257
18.8.3 Example 3: synchronously restarting a group of processors ... 257
18.8.4 Example 4: halting a single processor on Performance Monitors overflow ... 258
19
APPENDIX: RATIONALE AND IMPLEMENTATION NOTES ... 258
19.1 Backwards compatibility for AArch32 state ... 258
19.2 Debug exceptions ... 258
19.2.1 Exception routing and enabling ... 258
19.2.2 Enabling Software Step independently of Breakpoints and Watchpoints ... 259
19.2.3 Secure debug disable, MDCR_EL3.SDD ... 259
19.2.4 Debug event mask, PSTATE.D ... 259
19.2.5 Debug exception routing and authentication, ARMv7-A ... 260
19.3 Breakpoint and watchpoints ... 261
19.3.1 Address matching ... 261
19.3.2 Context ID and VMID matching ... 262
19.3.3 Processor state matching ... 262
19.3.4 Determining the address of a watchpointed location ... 262
19.3.5 Number of breakpoints and watchpoints ... 262
19.4 Single-step ... 262
19.4.1 Software Step and AArch32 state ... 263
19.5 Software breakpoint instructions ... 263
19.6 Exception catching ... 263
19.6.1 Vector Catch and self-hosted debug ... 263
19.7 External debug request ... 263
19.8 Debug exception model ... 264
19.8.1 Virtual debug exceptions ... 264
19.9 External debug over power-down ... 264
19.10 Performance Monitors ... 264
19.10.1 Size of counters ... 264
19.10.2 Extending User mode access counters ... 264
19.11 Debug state ... 265
19.11.1 Backwards compatibility for v7-A debuggers ... 265
19.11.2 Entering Debug state ... 265
19.11.3 Implementing DLR and DSPSR ... 265
19.11.4 Behavior of instructions executed in Debug state ... 265
19.11.5 Preferred behavior for instructions in Debug state ... 266
19.11.6 Security in Debug state ... 272
19.11.7 Privilege in Debug state ... 272
19.11.8 Accessing registers in Debug state ... 272
19.11.9 Accessing memory in Debug state ... 272
19.11.10 EDSCR.INTdis ... 273
19.12 Debug registers ... 273
19.12.1 Debug Status and Control Register, DBGDSCR, in v7-A ... 273
19.12.2 ROM table address registers ... 273
19.12.3 Debug comms channel ... 274
19.12.4 APB memory map ... 274
20
APPENDIX: PRINCIPLES OF DEBUG MEMORY MAPS ... 275
20.1 64KB pages ... 275
20.2 16KB pages ... 276
20.3 4KB pages ... 276
21
APPENDIX: RECOMMENDATIONS FOR PERFORMANCE MONITORS ... 278
21.1 Recommendations for Performance Monitors Event Numbers for IMPLEMENTATION DEFINED Events 278 21.1.1 House style event clarifications ... 279
21.1.2 Categorization of exceptions ... 280
21.1.3 Renaming of speculative events ... 281
21.2 Recommended mapping to Linux perf events ... 282
21.2.1 Generalized hardware CPU events (PERF_TYPE_HARDWARE) ... 282
21.2.2 Hardware CPU cache event (PERF_TYPE_HW_CACHE) ... 283
22
APPENDIX: MISCELLANEOUS PSEUDOCODE FUNCTIONS ... 283
22.1 Miscellaneous configuration functions ... 284
22.2 State extraction ... 284
22.3 Other miscellaneous functions... 285
22.4 Miscellaneous debug functions... 286
22.5 Executing an instruction in Debug state ... 287
23
APPENDIX: EXAMPLES OF HARDWARE SINGLE STEP ... 287
23.1 Software Step of a simple instruction ... 288
23.2 Software Step and exceptions ... 289
23.2.1 Debugger at EL1 ... 290
23.2.2 Debugger at EL2 ... 292
23.2.3 Stepping off debug exceptions ... 293
23.2.4 Software Step and a kernel debugger ... 293
23.2.5 Stepping over high-priority interrupts ... 295
23.2.6 UNPREDICTABLE changes in state ... 296
23.3 Software Step and Illegal exception return ... 296
23.4 Taking asynchronous exceptions from active-pending ... 298
23.5 Stepping an exception caught by Vector Catch ... 299
23.6 Halting Step ... 300
23.6.1 Halting Step and changes to debug authentication ... 303
23.6.2 Halting Step and Software Step ... 304
24
APPENDIX: DEBUG RESTART RACE CONDITIONS ... 304
24.2 Multicycle Restart Request trigger event ... 305
25
APPENDIX: RECOMMENDED EXTERNAL DEBUG INTERFACE ... 306
25.1 Overview ... 306
25.2 Details ... 307
25.2.1 Recommended authentication interface ... 308
25.2.2 EDBGRQ and DBGACK ... 309
25.2.3 PMUEVENT bus ... 310
25.3 Implementation of the Cross-Trigger Interface with a CoreSight CTI ... 310
ABOUT THIS DOCUMENT
Document structure
Part A: Background and Requirements starting on page 14 provides the reader with background information as to the goals and purpose of the ARMv8 debug model.
Part B: ARMv8 Self-hosted Debug starting on page 21 is the draft reference manual for v8-A debug. Part C: Performance Monitors Extension starting on page 97 describes the v8-A Performance Monitors. Part D: ARMv8 External Debug starting on page 126 provides additional draft reference material for implementations and external debuggers.
Part E: Appendices starting on page 241 provides additional material including using debug, detailed rationales and other background information.
See Read Me First! on page 15.
References
Reference Document number Title
[v7A] ARM DDI 0406 ARM® Architecture Reference Manual, ARMv7-A and ARMv7-R edition [Debug7.1] DS109-GENC-009251 ARM® Debug Architecture v7.1
[ADIv5] ARM IHI 0031 ARM® Debug Interface version 5 [v8Exception] PRD03-GENC-009432 ARMv8 Exception Model
[A64] PRD03-GENC-010198 ARMv8 ISA new encodings
[v8Translation] PRD03-GENC-009612 ARMv8 Translation Table System and Memory Model [CTI] ARM DDI 0314 CoreSight™ Components Technical Reference Manual [ETMv4] ARM IHI 0064 ETMv4 Architecture Specification
[PIL] ARM-EPM-021356 Processor Integration Layer Specification
[SharedPCode] shared_pseudocode.xml ARMv8 Library Pseudocode (from ISA XML database) [AArch32UNP] PRD03-GENC-010544 AArch32 UNPREDICTABLE behaviours
[CoreSight] ARM IHI 0029 CoreSight™ Architecture Specification [APB3] ARM IHI 0024 AMBA® APB Protocol Specification
[ATB] ARM IHI 0032 AMBA 4 ATB Protocol Specification
[GICv3] PRD03-GENC-010745 GIC Architecture Specification
[perf] perf.wiki.kernel.org perf: Linux profiling with performance counters
Terminology
v8-A, v7-A, v7-M and v6 refer to different versions of the ARM architecture.
v7 Debug and v7.1 Debug refer to the versions of debug for v7-A defined by [v7A] issue C.
AArch64 and AArch32 refer to the Execution state, 64 bit and 32 bit, respectively, as defined by [v8Exception]. RES0 and RES1 are defined by [v8Exception].
EL means Exception level, as defined by [v8Exception].
EL3 and EL2 are OPTIONAL, meaning it is IMPLEMENTATION DEFINED whether ELx is implemented.
ELx using AArch32 is not supported means that the implementation supports only AArch64 state at ELx and higher. Do not confuse with an implementation that is programmed to use AArch64 at ELx.
If EL3 is not implemented, the processor is Secure if can access both Secure and Non-secure memory, and the processor is Non-secure otherwise.
Note: [v8Exception] lists the implementation options permitted by the architecture. Reference to an option in this document does not imply such an implementation is permitted by the architecture.
PART A: BACKGROUND AND REQUIREMENTS
1 READ ME FIRST!
1.1 Document status
This is an update to the EAC release of the ARMv8 debug architecture. For a summary of the recent changes, see Appendix: Recent Change History on page 310.
1.1.1 Differences between this document and DDI0487A
At the time of writing, this document remains the definitive reference of the ARMv8 debug architecture. The consolidated ARMv8 Architecture Reference Manual (ARMv8 ARM) is a work-in-progress and may contain errors. When the ARMv8 ARM becomes the definitive reference, this document will be withdrawn.
The consolidated ARMv8 ARM will include some differences of approach to the architecture which are not reflected in this document, but which do not change the architecture definition. These are described briefly in the following sections.
Separate definitions and pseudocode for AArch32 and AArch64 self-hosted debug
This document unifies most of the descriptions for AArch32 and AArch64 self-hosted debug. The pseudocode generally applies to both. Where the text or pseudocode references an AArch64 system register it is implicitly referencing the mapped AArch32 system register if run in AArch32 state.
The ARMv8 ARM splits the self-hosted debug model into separate sections for AArch32 and AArch64, as part of the exception models.
Re-factored pseudocode
In the ARMv8 ARM, the debug pseudocode is also split into AArch32 and AArch64 versions, which allows a number of simplifications in places, and is integrated into the exception model and memory model
pseudocode. The structure and API of the exception model pseudocode in the ARMv8 ARM differs slightly from that used in this manual. In particular, the TakeException functions differ.
Debug events and debug exceptions
This document broadly uses the following logical model: The PE generates a Software or Halting debug event the debug event generates entry to Debug state if either:
— The event is a Halting debug event
— The event is a Breakpoint or Watchpoint debug event, EDSCR.HDE is set to 1 and halting is allowed,.
(Otherwise) if the event is a Software debug event, it generates a debug exception.
The ARMv8 ARM uses a simplified logical model that removes unnecessary references to debug events from the description of self-hosted debug:
Breakpoints and Watchpoints can either be debug exceptions or debug events: — A debug event if EDSCR.HDE is set to 1 and halting is allowed
— A debug exception otherwise.
All other events described in this document as Software debug events are only described in the ARMv8 ARM as exceptions.
All Halting debug events are simply debug events.
1.2 Required reading
It is useful if the reader is familiar with the basic concepts of v7-A, as this document does not reproduce all of those concepts. Those concepts are defined by the ARM Architecture Reference Manual ([v7A]). (On release of issue C, this includes v7.1 Debug, Performance Monitors version 2, LPAE, and the Virtualization
Debug, and in particular debug exceptions, has significant overlap with the v8-A exception model
[v8Exception]. This document assumes the reader is familiar with the v8-A exception model. The program-flow trace extension for v8-A is described separately in [ETMv4].
2 INTRODUCTION TO ARMV8 DEBUG
2.1 Introduction
Debug enables a platform’s software developers to create applications, middleware and platform software that meets the three key criteria of high performance, lower power consumption, and reliability.
External debug features were first introduced on v4 architecture processors to support developers using embedded and deeply-embedded processors, and has evolved into a broad portfolio of debug and trace features.
Support for rich application software platforms, in particular support for self-hosted debug and performance profiling, has been a more recent addition, in v6 and v7-A.
Self-hosted debug
To enable a mass-market of developers creating rich applications, a platform requires development tools that often run (at least in part) on the application processor itself rather than requiring expensive interface
hardware to connect a second “host” computer. v8-A refines the architecture’s support for this self-hosted form of debug. On existing desktop platforms, self-hosting is the prevalent method for software development. Semi-hosting is a variant of self-hosting where a host computer is used to offload much of the work of a tool (such as the user interface, debug illusion, symbol management, etc.) from the target, usually using a low-cost interface (such as USB or Ethernet) to connect to the target. The architecture has no need to distinguish between semi- and self-hosting.
Self-hosted debug is documented in Part B: ARMv8 Self-hosted Debug starting on page 21. Note: Self-hosted debug is also known as monitor or foreground debug.
External debug
However, often a complex system requires much of its hardware and software to be functional before any standard interfaces can be used for debug. It is very important to be able to get debug a system without relying on the system being debugged. This needs reliable external debug – that is, hardware-assisted, run-control debug and trace features, all of which can be run-controlled without the need for software operating on the platform – often very early in the product design cycle.
Self-hosted tools usually require layers of software support, making it difficult to debug parts of the software, or making debugging too invasive for diagnosing some kinds of bug. Low-cost external debug interfaces, such as Serial Wire Debug (SWD) also help extend the range of applications where external debug is attractive. External debug is documented in Part D: ARMv8 External Debug starting on page 126.
Note: External debug is also known as halting or background debug.
Performance profiling
Self-hosted and external debug help a developer improve the reliability of the system. The other key aspects of raising performance and lowering power consumption can be addressed using performance profiling. For many applications developers, the scope for performance optimization is somewhat limited, as they rely on middleware layers delivered by the platform. For those developing middleware platforms for the ARM architecture, performance optimization is critical. For a complex SoC, profiling must not measure only the processor but the whole platform.
Performance Monitors are described in Part C: Performance Monitors Extension starting on page 97
2.2 Overview
2.2.1 The debug model
The debug logic of the processor is responsible for generating debug events. Debug events include events such as a breakpoint unit matching the address of an instruction against the address stored in its registers.
The processor turns a debug event into one of a number of actions, namely: 1. generate a debug exception
2. enter a special Debug state
3. pend the debug event, and convert it into an action later 4. ignore the debug event.
Debug exceptions are the basis of the self-hosted debug model. Debug state is the basis of the external debug model.
The conversion of debug events into exceptions or entry to Debug state depends on the configuration of the debug logic and the type of debug event. For example, some debug events never cause entry to Debug state and others never cause a debug exception. A debug event is never converted into both a debug exception and an entry to Debug state.
Sometimes the processor is not able to convert the debug event into one of these actions, despite the
configuration of the debug logic. This is because to do so would breach the security model of the processor. If the processor is executing in Secure state and the external debugger attached to it is not trusted, the
processor will not allow entry to Debug state.
In the simplest cases, if the debug event is neither converted into an exception nor a Debug state entry it is ignored or pended, depending on the nature of the event (whether it is one that can sensibly be pended). However, in the case of breakpoint instructions the processor must assume the instruction has replaced an actual program instruction; in these cases an exception is generated.
Self-hosted debug
Self-hosted debug supports several usage models:
Application debugging: debug exceptions generated by an application (EL0) and handled by an operating system (EL1). Debug exceptions are not generated from EL1.
Kernel debugging: debug exceptions can be generated from both EL0 and EL1 and taken to EL1. Allows a kernel debugger extension to an operating system to make use of hardware debug features. Features exist to prevent re-entrant exceptions within critical code regions. Kernel debugging must be enabled separately from application debugging.
OS debugging: in Non-secure debug exceptions from EL0 and EL1 can be routed to a hypervisor (EL2), as in the v7-A Virtualization Extensions. This allows the hypervisor to debug a guest operating system.
Hypervisor debugging: applies the kernel debugging feature to EL2, allowing a kernel debugger extension to a hypervisor.
Note: This manual uses the term “kernel debugging” to cover both debugging of an operating system at EL1 by a debugger at EL1 and of a hypervisor at EL2 by a debugger at EL2. The architecture does not support routing of debug events to a Secure monitor (EL3).
These controls are entirely governed by software control, meaning device-specific software to enable self-hosted debugging is not required in v8-A.
Note: This is also true for AArch32 operation. However, for backwards compatibility with v7 systems, Secure monitor software can optionally restrict self-hosted debug in AArch32 Secure state to be controlled by a compatible external authentication interface.
The virtualization extensions for debug also allow the hypervisor to share hardware debug resources between guest operating systems, and emulate self-hosted debug within a guest; see Concurrent use of debug by multiple agents, and ownership of debug resources on page 19.
External debug
The basic principles of halting debug are unchanged from v7-A. That is:
when programmed for halting debug, a debug event causes entry to a special Debug state
in Debug state, the processor does not fetch instructions from memory, but from a special Instruction Transfer Register
Data Transfer Registers are used to move register and memory contents between host and target. An important characteristic of an external debugger is that it is operating concurrently and (possibly) independently of the process or processor being debugged, and debugging must be possible out of device reset. As such an external authentication interface is also used for external debuggers in v8-A.
2.2.2 Basic feature set
The debug support in v8-A consists of:
two debug-modes: Monitor for self-hosted debug and Halting for external debug software breakpoint instruction
halting breakpoint instruction
2-16 hardware breakpoints (extended to long virtual addresses) 2-16 hardware watchpoints (extended to long virtual addresses)
Note: A watchpoint is a debug event generated on a data address match, also known in the industry as a data breakpoint. In ARM architectures, a breakpoint is always a debug event generated by the (attempted) execution of an instruction, based either on its address (hardware) or on the instruction itself (software).
hardware single-step, for both self-hosted and external debug (new to v8-A)
exception catching for external debug (similar to Vector Catch, but not available for self-hosted debug) run-control functions for external debug (start, stop)
a debug communications channel
software-assisted power-down support for external debug performance monitors.
An OPTIONAL Trace extension component is also available for v8-A processors.
2.2.3 Key differences from v7-A
In v7-A, the distinction between self-hosted debug and external debug was blurred. This has caused problems, particularly for self-hosted debug. In v8-A these styles of debug are more clearly separated.
Self-hosted debug
In v8-A debug exceptions are fully accommodated within the exception model. This means that, in v8-A, software breakpoint instructions and other debug events are implemented in a different way than in v7-A:
The v8-A exception model ([v8Exception]) allows for debug exceptions to be implemented as an independent class of synchronous exception. In v7-A, they are overloaded on-top of Prefetch (Instruction) and Data Aborts.
The software breakpoint instruction is a different instruction to the halting breakpoint instruction. In v7-A the single breakpoint instruction was modal.
A hardware single-step is provided.
Generation of debug exceptions is under the control of software, with no dependency on an external authentication interface. There is no requirement for platform specific code to enable self-hosted debug. In v7-A, debug exceptions can be enabled or disabled externally through an authentication interface. Platform specific code might be needed to setup this interface.
v8-A continues to support a debug comms channel and lightweight power-down support.
v8-A remains software compatible with v7-A, for running AArch32 operating systems or AArch32 hypervisors within an otherwise AArch64 system. This means some additional features defined by [v7A] are supported in AArch32 state, if any of EL3, EL2 or EL1 is using AArch32:
The Secure User debug enable function, in Secure EL0. In AArch64 the kernel debug enable function provides the same capability.
Vector Catch and Address Mismatch breakpoint debug events. See also Compatibility for v7-A (32-bit) software on page 20.
External debug
As in v7-A, v8-A also supports external debug, that is assisting hardware bring-up and remote debugging. The main feature differences from v7-A are:
as noted above, the halting breakpoint instruction is distinct from the software breakpoint instruction exception catching in v8-A is extensively simplified compared to that in v7-A; the Vector Catch
breakpoints of v7-A are not supported for halting debug the addition of hardware single-step.
The v8-A definition of Debug state is intended to be cleaner than that in v7-A, with fewer changes to the processor’s behavior when in Debug state. For example:
The additional privilege afforded to Debug state is restricted to the ability to execute debug state instructions, which are UNDEFINED in Non-debug state. Unlike with v7-A, for example, a v8-A debugger cannot access privileged registers from unprivileged modes.
v8-A defines a list of instructions that debuggers must use, rather than guaranteeing that every instruction can be executed in Debug state.
The debugger accesses the target PC and PSTATE through special access instructions, rather than using MOV and MRS/MSR to access “frozen” PC and PSTATE values.
2.2.4 Debug register interfaces
There are several possible clients of debug: self-hosted debug monitors
off-chip external debuggers, also known as “JTAG debuggers” on-chip external debuggers.
To support these different clients, the architecture supports three types of access to the debug registers: using MSR and MRS instructions in AArch64 state and CP14 and CP15 MCR and MRC instructions in
AArch32 state to a system register interface, for self-hosted debuggers
from a Debug Access Port (DAP) to an external debug interface, for off-chip external debuggers OPTIONAL memory-mapped access to the external debug interface, for on-chip external debuggers.
System register interface External debug interface Debug register interfaces
MSR and MRS in AArch64 state
CP14 and CP15 MCR and MRC in AArch32 state
Debug Access Port (DAP) accesses Memory-mapped accesses
Figure 1: Debug register interfaces taxonomy
For the external debug interface, ARM strongly recommends the use of an ARM Debug Interface v5 (ADIv5) DAP. ADIv5 allows multiple processors to be accessed through a single DAP. Implementation of ADIv5 is a pre-requisite for many debug toolchains. See [ADIv5].
CoreSight provides an implementation of ADIv5, including a DAP and a debug interconnect based on AMBA APB3 that supports multiple debug slave ports for multiple processors. CoreSight also defines interconnects for the cross-trigger matrix (CTM) described in Embedded Cross-Trigger on page 179 and for the OPTIONAL Trace extension. See [CoreSight].
The two access mechanisms for the external debug interface are largely identical. This manual describes the common features, with important differences called out where necessary. Memory-mapped accesses to the external debug interface on page 193 summarizes the main differences. Use of CoreSight allows DAP and memory-mapped accesses to be implemented as a single external debug interface port on the processor.
2.2.5 Concurrent use of debug by multiple agents, and ownership of debug
resources
The various clients of debug share various debug resources, for example:
there is only one set of breakpoint and watchpoint units, with shared control registers for debug monitors, there is only a single single-step debug resource.
The extent to which the architecture needs to support these models concurrently affects certain aspects of the architecture.
Self-hosted debug monitors
Multiple debug monitors in multiple guest operating systems can co-exist if higher levels of software (i.e. EL3 or EL2) are aware of this use and context switch the debug registers.
Where debug hardware is used (for example, for breakpoints, watchpoints and single-step) accesses to the debug registers by software can be trapped to higher Exception levels. This allows, for example, an EL2
hypervisor to be aware of which guest operating systems are using debug hardware and optimize context switching appropriately. The hypervisor can detect which operating systems are using hardware debug resources, meaning it can optimize switching the resources between operating systems.
Running multiple debug monitors at both EL2 and EL1 is a useful usage model, particularly in server and high-performance computing applications. For example, an administrator can debug a test version of the system using a hypervisor-resident debug monitor at the same time as users debug their code under a deployed kernel.
v8-A allows some of these mixed use cases without any overhead. In addition to trapping debug register accesses, the EL2 hypervisor can also independently route debug exceptions to itself, deciding which to process itself and which to route back to the guest. Thus, a hypervisor can emulate debug exceptions within the guest operating system, if it needs to. For breakpoints and watchpoints, this is relatively straightforward. Note: Emulating use of hardware single-step within a guest operating system, whilst possible, may not be
optimal. ARM does not consider this to be a serious limitation of the debug architecture.
Co-operative use of debug resources by multiple agents is a software problem for those agents to resolve outside of the bounds of the architecture.
External debuggers
Mixing on- and off-chip external debuggers is not a supported use case; neither is supporting multiple external debuggers. Scenarios exist where there are multiple debuggers or debugger-like programs (e.g. a debugger and a profiler), but co-operative use of the debug resources by such programs is a software problem for those programs to resolve outside of the bounds of the architecture.
Mixed use
The phase in a product’s lifetime when the use of debug monitors and external debuggers overlap is small, if not non-existent. It is possible to define the architecture to support such a mixed use model, but it quickly becomes very complicated. As such, this is not a primary concern of the architecture.
2.2.6 Multi-processing
v8-A defines cross-triggering features as part of the architecture. In v7-A this is an IMPLEMENTATION DEFINED feature; for example, provided by a CoreSight cross-trigger interface (CTI). This is discussed in more detail in Embedded Cross-Trigger on page 179.
2.2.7 Performance monitors
A 64-bit architecture does not impose any radical additional requirements on the performance monitors; in particular ARM does not propose increasing the size of the performance monitor counters for v8-A.
ARM recognizes the need for high performance microprocessors to have an improved level of performance monitoring capability beyond that offered by v7-A. Such changes to the performance monitoring architecture are not directly related to the 64-bit-ness of v8-A, and so are outside of the scope of this document.
See Performance Monitors on page 97 for more information.
2.2.8 Other areas of debug within ARM architectures
Co-incident with the development of v8-A, ARM is developing a new trace architecture extension to address trace for advanced microarchitectures. This trace extension will fully accommodate v8-A. See [ETMv4].
2.3 Compatibility for v7-A (32-bit) software
Software that makes use of the v7-A definition of Monitor debug-mode must continue to function on v8-A architecture processors.
All the software-visible features of v7-A are supported in AArch32 modes in v8-A.
If the processor supports executing AArch32 code only at EL0, the extent of this backwards compatibility requirement is greatly diminished, as debug mostly impacts the exception model.
External debuggers that make use of halting debug-mode must be modified to use the v8-A Debug state programmer’s model. Supporting both the v7-A and v8-A definitions of Debug state would unnecessarily burden v8-A.
PART B: ARMV8 SELF-HOSTED DEBUG
3 SOFTWARE DEBUG EVENTS
3.1 About Software debug events
Software debug events are: Breakpoint debug event on page 23 Watchpoint debug event on page 33 Software Step debug event on page 39
Software Breakpoint Instruction debug event on page 48 Vector Catch debug event on page 49.
Other than the cases described in Use of breakpoints and watchpoints by external debug below: Breakpoint, Watchpoint, and (from AArch32 state) Vector Catch debug events will:
— generate a debug exception to the debug exception target Exception level if enabled for the current security state and Exception level
— be ignored otherwise.
Software Step is inactive when debug exceptions are disabled, meaning Software Step debug events are generated only when debug exceptions are enabled.
Software Breakpoint Instruction debug events always generate a debug exception.
For the definition of the debug exception target EL, see Routing debug exceptions on page 52. For the definition of enabled see either:
Enabling debug exceptions other than Software Breakpoint Instruction routed to an EL using AArch64 on page 53
Enabling debug exceptions other than Software Breakpoint Instruction routed to an EL using AArch32 on page 54.
Whether an exception is enabled depends partly on indirect reads of registers and other processor state. This means the behavior can be CONSTRAINED UNPREDICTABLE if the conditions change. See Synchronization and Software debug events on page 51.
Debug exception prioritization on page 60 describes the behavior where multiple debug events are generated by an instruction.
Table 1 summarizes the behavior of and locates the pseudocode for each Software debug event.
Debug event type Outcome Pseudocode details
if enabled if disableda
Breakpoint debug event on page 23
Address Mismatch Breakpoint Exception Ignored CheckSoftwareStep
other Breakpoint Exceptionb Ignored CheckBreakpoint
Watchpoint debug event on page 33 Exceptionb Ignored CheckWatchpoint
Software Step debug event on page 39 Exception n/a CheckSoftwareStep
Software Breakpoint Instruction debug event on
page 48 Exception Exception
BRKInstruction (AArch64)
BKPTInstruction (AArch32)
Vector Catch debug event on page 49 Exception Ignored CheckVectorCatch
a. For the definitions of enabled and disabled, see Debug Exception Model on page 52. b. See also Use of breakpoints and watchpoints by external debug below.
Table 1: Summary of Software debug events and possible outcomes within self-hosted debug
3.1.1 Legacy debug events
Legacy debug events are: Vector Catch debug events
breakpoints programmed to match only in User, Supervisor and System modes (DBGBCRn_EL1.PMC == 0b00).
Legacy debug events are enabled only when using an AArch32 stage 1 translation regime, and are supported only if EL1 using AArch32 is supported.
Note: EL3, EL2 and EL1 use an AArch32 stage 1 translation regime when that EL is using AArch32. EL0 uses an AArch32 stage 1 translation regime when EL1 is using AArch32. See Table 2 and Legacy debug events and HCR_EL2.{TGE,TDE} below.
# a Exception levels using AArch32
Stage 1 translation regimes Legacy debug events at
EL3 EL2 EL1&0 EL3 EL2 EL1 EL0
A None (all AArch64) AArch64 AArch64 AArch64 Disabled Disabled Disabled Disabled
B EL0 only AArch64 AArch64 AArch64 Disabled Disabled Disabled Disabled
C EL1 and EL0 AArch64 AArch64 AArch32 Disabled Disabled Enabled Enabled D EL2, EL1 and EL0 AArch64 AArch32 AArch32 Disabled Disabledc Enabled Enabled E EL3c, EL2, EL1 and EL0 AArch32 AArch32 AArch32 Enabled Disabledc Enabled Enabled
a. Configuration index used in other tables.
b. For compatibility with ARMv7, debug events other than Software Breakpoint Instruction debug events never generate debug exceptions from EL2 using AArch32.
c. That is, in all Secure privileged modes.
Table 2: Treatment of legacy debug events in different states EL3 execution
state SCR.RW
a
SCR.NS a HCR.RW a # b Legacy debug events at
EL3 EL2 EL1 EL0
AArch64 1 1 1 A or B Disabled Disabled Disabled Disabled
0 -
1 0 C Disabled Disabled Enabled Enabled
0 0 -
1 RES0 D Disabled Disabled Enabled Enabled
AArch32 RES0 X RES0 E Enabled Disabled Enabled Enabled
a. SCR and HCR registers should be taken to be the effective values of SCR_EL3 and HCR_EL2 when the appropriate Exception level is using AArch64. If EL3 is using AArch32, the SCR.RW is a notional bit in the SCR that is RES0. If EL2 is using AArch32, the HCR.RW is a notional bit in the HCR that is RES0. [v8Exception] defines other conditions where the processor must behave as if these bits have a fixed value, for example, if AArch32 is not supported at all Exception levels.
b. Configuration defined by Table 2.
Table 3: Table 2 with Exception levels using AArch32 expanded to show system register settings
In an AArch64 stage 1 translation regime, legacy debug events are disabled: Vector Catch debug events are not generated
Breakpoints programmed to match only in User, Supervisor and System modes do not generate Breakpoint debug events. These types of breakpoints are reserved.
Breakpoints programmed as Address Mismatch breakpoints are either evaluated as another type of breakpoint or do not generate Breakpoint debug events. These types of breakpoints are reserved. Software must not rely on these properties as the behavior of reserved values might change in a future revision of the architecture.
Legacy debug events and HCR_EL2.{TGE,TDE}
If EL2 is using AArch64 and HCR_EL2.RW is set to 0, then the EL1&0 stage 1 translation regime is AArch32 and legacy debug events are enabled from EL0 and EL1, even if either of the following are true:
HCR_EL2.TGE is set to 1, meaning all exceptions are routed to EL2. EL1 is disabled. HCR_EL2.TDE is set to 1, meaning all debug exceptions are routed to EL2.
In both cases, legacy debug events are enabled from EL0, and, the TDE case from EL1. However, debug exceptions are routed to EL2 using AArch64.
Legacy debug events and external debug
When EDSCR.HDE is set to 1 and halting is allowed:
Breakpoints programmed as Address Mismatch breakpoints are either evaluated as another type of breakpoint, and so can generate Breakpoint debug events causing entry to Debug state, or do not generate Breakpoint debug events.
Breakpoints programmed to match only in User, Supervisor and System modes generate Breakpoint debug events causing entry to Debug state only from an AArch32 stage 1 translation regime.
Vector Catch debug events are unchanged and will generate debug exceptions only from an AArch32 stage 1 translation regime. Vector Catch debug events never cause entry to Debug state.
For more information see Halting the processor on debug events on page 138.
Pseudocode details of legacy debug events
// Function 1: LegacyDebugEventsEnabled // ====================================
boolean LegacyDebugEventsEnabled()
// Called for Address Mismatch Breakpoint and Vector Catch debug events return UsingAArch32() && PSTATE.EL != EL2 && ELUsingAArch32(EL1);
// Function 2: AllowMismatchBreakpoints // ====================================
boolean AllowMismatchBreakpoints()
return LegacyDebugEventsEnabled() && !HaltOnBreakpointOrWatchpoint();
3.1.2 Use of breakpoints and watchpoints by external debug
Breakpoint and Watchpoint debug events can also be used to halt the processor and enter a special Debug state for external debug. The architecture also defines an additional set of Halting debug events.
For more information see Halting the processor on debug events on page 138.
3.2 Breakpoint debug event
Rationale: see Breakpoint and watchpoints on page 261.
Address breakpoints generate debug events by comparing values held in system registers with instruction addresses.
Note: Do not confuse Breakpoint debug events generated by debug hardware comparators and Software Breakpoint Instruction debug events generated by executing software breakpoint instructions. Some breakpoints are context-aware and can be programmed as Context breakpoints that compare with the values of the context ID and/or (in Non-secure state) VMID.
A breakpoint can be programmed to match only in certain modes, Exception levels and security states. Address breakpoints can be linked to Context breakpoints.
The number of breakpoints in a processor is IMPLEMENTATION DEFINED. See Numbers of resources on page 69.
3.2.1 Programming Breakpoint debug events
Each breakpoint is defined by:
A Breakpoint Value Registers, DBGBVRn_EL1 (page 70). DBGBVRn_EL1 is a 64-bit register in AArch64 state, the bottom half of which is accessible in AArch32 state. If EL2 is implemented then the top half of context-aware breakpoints can be accessed in AArch32 state as DBGBXVRn.
A Breakpoint Control Registers, DBGBCRn_EL1 (page 71).
If DBGBCRn_EL1.E == 0, the breakpoint does not generate any debug events
If MDSCR_EL1.MDE == 0, breakpoints do not generate debug exceptions. This bit is DBGDSCR.MDBGen in AArch32 state. See Monitor Debug System Control Register, MDSCR_EL1 on page 77.
See also Constraints on programming Breakpoint debug events on page 28.
3.2.2 Breakpoint types
Address breakpoints. In an AArch32 stage 1 translation regime, when halting is disabled or EDSCR.HDE is set to 0, an Address breakpoint can be either
— an Address Match breakpoint — an Address Mismatch breakpoint.
In an AArch64 stage 1 translation regime or when halting is enabled and EDSCR.HDE is set to 1, an Address breakpoint is always an Address Match breakpoint.
Context breakpoints. A Context breakpoint can be any of: — a Context ID match breakpoint
— a VMID Match breakpoint
— a VMID and Context ID Match breakpoint.
A Linked Address breakpoint is associated with a Linked Context breakpoint to provide an instruction address match that is generated only within a given context. Other breakpoints are Unlinked.
Breakpoints
Unlinked Linked
Address
Context
(context-aware breakpoints only)
Linked Address Linked Context Unlinked Address Unlinked Context Address Match Address Mismatch (AArch32 translation regime and debug exceptions only)
Context ID Match
VMID Match
(only if EL2 is implemented)
VMID and Context ID Match (only if EL2 is implemented)
0b0000
Unlinked Address Match Linked Address Match0b0001
0b0100
Unlinked Address Mismatch
0b0101 Linked Address Mismatch
0b1000 Unlinked VMID Match
0b1001 Linked VMID Match 0b0010
Unlinked Context ID Match Linked Context ID Match0b0011
0b1010 Unlinked VMID and
Context ID Match
0b1011 Linked VMID and Context ID Match
Figure 2: Breakpoint taxonomy
Only some breakpoints are context-aware and can be programmed as either Address or Context breakpoints. Other breakpoints can only be programmed as Address breakpoints.
All other breakpoint types are reserved. See Breakpoint Control Registers, DBGBCRn_EL1 on page 71.
3.2.3 Address breakpoints
Address breakpoints compare the value stored in the DBGBVRn_EL1 system registers with the instruction virtual address.
The comparison with DBGBVRn_EL1 gives a match to the granularity of a word. Within this word: If AArch32 is supported at any EL, DBGBCRn_EL1.BAS is a read/write field that refines the
granularity of a breakpoint match to individual halfwords.
Otherwise, DBGBCRn_EL1.BAS is RES1 and the granularity of a breakpoint match is always a word. Note: Breakpoint address masking, OPTIONAL and deprecated in v7-A, is not supported in v8-A.
In an AArch64 stage 1 translation regime the eight most-significant bits of the 64-bit address are ignored when the applicable TBI bit in TCR_EL1, TCR_EL2 or TCR_EL3 is set to 1.
Note: The significant bits of DBGBVRn_EL1 system register are sign-extensions of the most-significant address bit, and breakpoints are lower priority than address faults, meaning that implementations can ignore these bits, and the TBI bit has no effect on the debug logic. In AArch32 state in an AArch64 stage 1 translation regime, 32 bit addresses are zero-extended before comparison. AArch64 software and external debuggers programming Address breakpoints to match in AArch32 state must write zeros to DBGBVRn_EL1[63:32].
In an AArch32 stage 1 translation regime the comparators compare only bits [31:0] of the address. Note: This is because software is not required to write the top 32 bits of DBGBVRn in AArch32 state for
Address breakpoints , meaning they contain an UNKNOWN value from reset and must be ignored. Writes to DBGBVRn registers in AArch32 state update only the bottom 32-bits of these registers.
3.2.4 Context breakpoints and linking
Context breakpoints compare the value stored in the DBGBVRn_EL1 system register with: the context ID value, from CONTEXTIDR_EL1 (32-bits)
Note: If EL3 is implemented and using AArch32 then CONTEXTIDR is a Banked register, and context-aware breakpoints depend on the current Banked copy of CONTEXTIDR. the VMID value, from VTTBR_EL2 (8-bits)
a concatenation of the context ID and VMID values (40-bits).
Multiple Linked Address breakpoints and watchpoints can be linked to a single Linked Context breakpoint. It is not possible to link:
to an Address breakpoint to any watchpoint
to an Unlinked Context breakpoint
one Context breakpoint to a second Context breakpoint.
Note: Context ID masking, OPTIONAL in v7-A and deprecated when LPAE is used, is not supported in v8-A. VMID and context ID matching is not done at EL2, or at EL3 using AArch64, and VMID matching is not done in Secure state, and such breakpoints do not match in those states.
Note: Context ID matching is done at EL3 using AArch32, for backwards compatibility.
3.2.5 Processor state matching
The breakpoint specifies the Exception level(s) in which the breakpoint matches. The breakpoint can also be restricted by linking it to a Linked Context breakpoint.
This allows breakpoints to be masked at different Exception levels without the need for active switching between tasks.
Processor state matching is controlled by DBGBCRn_EL1.{SSC, HMC, PMC}. Table 4 lists permitted values for these fields. In this table:
Only
AA32 means the entries in that row apply only in an AArch32 stage 1 translation regime, and is reserved in an AArch64 stage 1 translation regime. In AArch64 stage 1 translation regimes:
— If EL1 using AArch32 is supported by this processor, the breakpoint is disabled. — Otherwise these entries will behave as another row in the table, or as if the breakpoint
is disabled.
AA64 means the entries in that row apply only in an AArch64 stage 1 translation regime, and is reserved in an AArch32 stage 1 translation regime. In AArch32 stage 1 translation regimes:
— If the highest Exception level is using AArch64, the breakpoint is disabled.
— Otherwise these entries will behave as another row in the table, or as if the breakpoint is disabled.
No EL3