diff options
author | David Brownell <dbrownell@users.sourceforge.net> | 2009-11-28 10:40:26 -0800 |
---|---|---|
committer | David Brownell <dbrownell@users.sourceforge.net> | 2009-11-28 10:40:26 -0800 |
commit | acbe054a38a45432f5948026e1e9258b4e2910c2 (patch) | |
tree | 126e4c5fbe6d3d8261e994171f7f45855bf59a16 /testing/examples/STR912Test/test_rom.hex | |
parent | 68889ea02f28bfd61f0b4b85aad4b0bf8826a947 (diff) | |
download | openocd+libswd-acbe054a38a45432f5948026e1e9258b4e2910c2.tar.gz openocd+libswd-acbe054a38a45432f5948026e1e9258b4e2910c2.tar.bz2 openocd+libswd-acbe054a38a45432f5948026e1e9258b4e2910c2.tar.xz openocd+libswd-acbe054a38a45432f5948026e1e9258b4e2910c2.zip |
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>
Diffstat (limited to 'testing/examples/STR912Test/test_rom.hex')
0 files changed, 0 insertions, 0 deletions