The processor ignores vector catch debug events on the Prefetch or Data Abort vectors while in Monitor debug-mode because these events put the processor in an unrecoverable state.
The debuggers must avoid other similar cases by following these rules, that apply only if the processor is in Monitor debug-mode:
if BCR[22:20] is set to b010, an unlinked context ID breakpoint is selected, then the debugger must program BCR[2:1] for the same breakpoint as stated in this section
if BCR[22:20] is set to b100 or b101, an IVA mismatch breakpoint is selected, then the debugger must program BCR[2:1] for the same breakpoint as stated in this section.
The debugger must write BCR[2:1] for the same breakpoint as either b00 or b10, that selects either match in only USR, SYS, SVC modes or match in only USR mode, respectively. The debugger must not program either b01 (match in any privileged mode) or b11 (match in any mode).
You must only request the debugger to write b00 to BCR[2:1] if you know that the abort handler does not switch to one of the USR, SYS, or SVC mode before saving the context that might be corrupted by a later debug event. You must also be careful about requesting the debugger to set a breakpoint or BKPT debug event inside a Prefetch Abort or Data Abort handler, or a watchpoint debug event on a data address that any of these handlers might access.
In general, you must only set breakpoint or BKPT debug events inside an abort handler after it saves the context of the abort. You can avoid breakpoint debug events in abort handlers by setting BCR[2:1] as previously described.
If the debugged code is not running in a privileged mode, you can prevent watchpoint debug events in abort handlers by setting WCR[2:1] to b10 for matching only nonprivileged accesses.
Failure to follow these guidelines can lead to debug events occurring before the handler is able to save the context of the abort, causing the corresponding registers to be overwritten, and resulting in Unpredictable software behavior.