target: uplevel add_{break,watch}point() error checks
commitacbe054a38a45432f5948026e1e9258b4e2910c2
authorDavid Brownell <dbrownell@users.sourceforge.net>
Sat, 28 Nov 2009 18:40:26 +0000 (28 10:40 -0800)
committerDavid Brownell <dbrownell@users.sourceforge.net>
Sat, 28 Nov 2009 18:40:26 +0000 (28 10:40 -0800)
tree126e4c5fbe6d3d8261e994171f7f45855bf59a16
parent68889ea02f28bfd61f0b4b85aad4b0bf8826a947
target: uplevel add_{break,watch}point() error checks

In target_type.h it's documented that the target must be
halted for add_breakpoint() ... and with slight ambiguity,
also for its add_watchpoint() sibling.  So rather than
verifying that constraint in the CPU drivers, do it in the
target_add_{break,watch}point() routines.

Add minor paranoia on the remove_*point() paths too:  save
the return value, and print it out in in the LOG_DEBUG message
in case it's nonzero.

Note that with some current cores, like all ARMv7 ones I've
looked at, there's no technical issue preventing watchpoint or
breakpoint add/remove operations on active cores.  This model
seems deeply wired into OpenOCD though.

ALSO:  the ARM targets were fairly "good" about enforcing that
constraint themselves.  The MIPS ones were relied on other code
to catch such stuff, but it's not clear such code existed ...
keep an eye out for new issues on MIPS.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
src/target/arm7_9_common.c
src/target/breakpoints.c
src/target/cortex_m3.c
src/target/target.c
src/target/target_type.h
src/target/xscale.c