Architectural Debug Triggers

The Base debug facility defines stopping events, trigger configuration, and retry behavior for one logical processor. External debugger transport, authentication, forced halt and resume, multicore coordination, and platform policy are outside the processor ISA.

Debug Event Identities

SINGLE_STEP is the post-success event selected by STATUS.TF. EXPLICIT_BREAKPOINT is the post-success event produced by BKPT. Both save the following architectural boundary.

EXECUTION_BREAKPOINT, MEMORY_READ_WATCHPOINT, MEMORY_WRITE_WATCHPOINT, and ATOMIC_MEMORY_WATCHPOINT are fault-like, pre-effect events. They save the current instruction for retry. The event identity itself states the stopping reason; there is no generic debug-cause event. TRACE records a trace-stream marker and permits execution to continue.

Trigger-Slot Array and Programming Model

Each logical processor owns an array of at least four trigger slots. The implementation reports the exact count through CPUID SLOT_COUNT. Trigger state is accessed by the supervisor-only DTRSEL/DTRDATA selector-data pair. DTRSEL.SLOT selects a slot and DTRSEL.BANK selects the word read or written through DTRDATA. WRCR to DTRSEL requires bits 63 through 18 to be zero, a slot below SLOT_COUNT, and a bank from zero through two; a successful write atomically replaces the selector.

DTRSEL Bank Selection

DTRSEL.BANK	Word	Meaning
0	CONFIG	validity, access-kind, and privilege-domain controls
1	LOW	inclusive low effective-address or PC bound
2	HIGH	exclusive high effective-address or PC bound
3	reserved	selection raises INVALID_CONTROL_SELECTOR

Debug-Trigger CONFIG Word

V, X, R, W, U, and S abbreviate CONFIG.VALID, CONFIG.MATCH_EXECUTE, CONFIG.MATCH_READ, CONFIG.MATCH_WRITE, CONFIG.MATCH_USER, and CONFIG.MATCH_SUPERVISOR.

Debug-Trigger CONFIG Fields

Field	Bit	Meaning
VALID	0	slot participates in matching
MATCH_EXECUTE	1	match instruction execution at the architectural PC
MATCH_READ	2	match instruction-owned data reads
MATCH_WRITE	3	match instruction-owned data writes
MATCH_USER	4	match accesses in the user permission domain
MATCH_SUPERVISOR	5	match accesses in the supervisor permission domain
reserved	63..6	reads as zero and must be zero when written

A slot is staged while CONFIG.VALID=0. Software writes CONFIG, LOW, and HIGH in any order, then writes CONFIG.VALID=1 as the final operation. Activation atomically validates that LOW is less than HIGH, at least one of CONFIG.MATCH_EXECUTE/CONFIG.MATCH_READ/CONFIG.MATCH_WRITE is set, at least one of CONFIG.MATCH_USER/CONFIG.MATCH_SUPERVISOR is set, and every reserved bit is zero. To replace an active slot, software first writes its current CONFIG image with only CONFIG.VALID cleared. While active, no other CONFIG change and no LOW or HIGH write is permitted. A successful WRCR to DTRDATA atomically replaces the selected staged word or activates the complete staged slot. A rejected write changes neither the slot nor the selector.

Matching Coordinates and Selection

Each slot describes one non-wrapping half-open range \([\mathrm{LOW},\mathrm{HIGH})\) using LOW and HIGH. An execution trigger matches when the pre-segment architectural PC is in that range. A data trigger matches when the byte range of an instruction-owned memory operation overlaps it; the compared coordinate is the pre-segment effective address. An exact one-byte range is expressed by HIGH=LOW+1.

Read and write matching may both be enabled. An atomic read-modify-write qualifies for both bits, but any winning match raises ATOMIC_MEMORY_WATCHPOINT. Trigger matching considers only range, access kind, and user or supervisor permission domain. Data values, masks, and value-change conditions are not part of the Base trigger model. If multiple slots match one operation, the lowest-numbered slot wins.

Pre-Effect Memory Evaluation

For a candidate memory operation, the processor validates the instruction and operands, resolves its condition or predicate, computes the effective address, and completes segmentation, translation, permission, and alignment validation before evaluating triggers. A winning trigger is reported before the memory or device access and before any architectural result commits. Consequently, earlier synchronous faults take priority; a matching load performs no read, a matching store is not visible, a matching atomic performs no read-modify-write action, and a matching MMIO operation does not access the device. A bus or data fault can still occur after event return when the operation is retried.

Explicit and implicit instruction data accesses participate. Instruction fetch, page-table walks, event-entry frame accesses, prefetch hints, and cache-maintenance accesses do not. False-conditioned operations and inactive vector lanes do not participate. REP and REPcc evaluate before each iteration’s memory effect and preserve completed prior iterations. Gather and scatter evaluate before the next active lane access and preserve completed lane and predicate progress.

Trigger State and Retry

Reset disables every slot and resets DTRSEL. Event entry does not modify the array. The array is per-processor debug state rather than computational context and is not part of any owner state record. STATUS.TF and STATUS.RF remain execution-context state. STATUS.RF suppression, automatic saved-image STATUS.RF for pre-effect hardware events, and event priority are specified in Event Priority and Debug Stops.