aboutsummaryrefslogtreecommitdiff
path: root/NEWTAPS
diff options
context:
space:
mode:
authorMatthias Welwarsky <matthias.welwarsky@sysgo.com>2017-10-05 14:50:16 +0200
committerMatthias Welwarsky <matthias@welwarsky.de>2018-02-21 08:20:28 +0000
commitb551c62a7ff4e97a947486904f09a2356f27ced5 (patch)
treecbf360e80ed0c241acdde6929bc883eaa7f376c0 /NEWTAPS
parentdd60dd84f28deb9dd485384466c4417b527ac3b2 (diff)
downloadriscv-openocd-b551c62a7ff4e97a947486904f09a2356f27ced5.zip
riscv-openocd-b551c62a7ff4e97a947486904f09a2356f27ced5.tar.gz
riscv-openocd-b551c62a7ff4e97a947486904f09a2356f27ced5.tar.bz2
cortex_a: fix handling of Thumb-2 32bit breakpoints
When debugging Thumb-2 code, Gdb will at times send a breakpoint packet 'Z0,<addr>,3', the number 3 denoting that the instruction to break on is 32 bits long. Handle this by replacing it with two consecutive 16bit Thumb BKPTs and make sure to save and restore the full, original 32bit instruction. Note that this fix is only applicable if you debug a bare-metal program (like the linux kernel) with the 'wrong' gdb, e.g. use an "arm-linux" gdb instead of an "arm-eabi" gdb. But since most people may not know about the subtle differences between gdb configurations regarding thumb2 breakpoints it's still valid. Change-Id: Ib93025faf35b11f0dba747a8c1fc36fd09a4c0f8 Signed-off-by: Matthias Welwarsky <matthias.welwarsky@sysgo.com> Reviewed-on: http://openocd.zylin.com/4241 Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de> Tested-by: jenkins
Diffstat (limited to 'NEWTAPS')
0 files changed, 0 insertions, 0 deletions