|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 21 – Debugging, Tracing, and Determinism > 21.7 Breakpoints and Watchpoints |
Supported breakpoint types: PC breakpoints (halt when PC matches a specified address), instruction-class breakpoints (halt on any instruction of a given opcode or grain class), PAL entry breakpoints (halt on PAL mode entry, optionally filtered by PalEntryReason), and exception breakpoints (halt when a specific ExceptionClass is delivered). Breakpoints trigger only at architectural boundaries — never mid-instruction — and preserve precise exception semantics. The BPT (breakpoint) and KBPT (kernel breakpoint) PAL calls provide architectural breakpoint support.
Watchpoints observe: memory reads (halt when a specific physical or virtual address is read), memory writes (halt on write to an address), register writes (halt when a specific register is modified), and IPR changes (halt on modification of a specific internal processor register). Watchpoints are observational and do not alter memory ordering or execution timing. They integrate with the EXECTRACE system — when a watchpoint fires, the current trace state provides full context for the triggering event.
When a debug event triggers: the pipeline drains to a precise architectural point, architectural state is frozen, the debugger may inspect all state (registers, memory, IPRs, TLB, reservation status, pending events), and no partial instruction effects exist. Single-step mode executes exactly one instruction, delivers a debug trap afterward, and preserves precise exception semantics. Debugger intervention (breakpoints, single-step) is treated as a controlled nondeterminism source — it is explicitly excluded from deterministic replay guarantees.
See Also: Chapter 20 – Boot Sequence, PAL, and SRM Integration (BPT/KBPT PAL calls).