Debug
ARM DDI 0363G
Copyright © 2006-2011 ARM Limited. All rights reserved.
12-46
ID073015
Non-Confidential
The debuggers must avoid other similar cases by following these rules, that apply only if the
processor is in Monitor debug-mode:
•
if DBGBCR[22:20] is set to b010, and unlinked context ID breakpoint is selected, then
the debugger must program DBGBCR[2:1] for the same breakpoint as stated in this
section
•
if DBGBCR[22:20] is set to b100 or b101, and instruction address mismatch breakpoint
is selected, then the debugger must program DBGBCR[2:1] for the same breakpoint as
stated in this section.
The debugger must write DBGBCR[2:1] for the same breakpoint as either b00 or b10, that
selects either match in only USR, SYS, or SVC modes or match in only USR mode,
respectively. The debugger must not program either b01, that is, match in any Privileged mode,
or b11, that is, match in any mode.
You must only request the debugger to write b00 to DBGBCR[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 abort context. You can avoid breakpoint debug events in abort handlers by setting
DBGBCR[2:1] as previously described.
If the code being debugged is not running in a Privileged mode, you can prevent watchpoint
debug events in abort handlers by setting DBGWCR[2:1] to b10 for match only non-privileged
accesses.
Failure to follow these guidelines can lead to debug events occurring before the handler is able
to save the context of the abort. This causes the corresponding registers to be overwritten, and
results in Unpredictable software behavior.