aboutsummaryrefslogtreecommitdiff
path: root/bfd/cpu-visium.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-04-10 10:36:23 +0100
committerPedro Alves <palves@redhat.com>2015-04-10 10:36:23 +0100
commit8d707a12ef51ba5f4c3c6a52532e903da7a56b8b (patch)
tree37c565150854b4dfaee0f9cb7968784d397b6396 /bfd/cpu-visium.c
parentef713951c571c8490ca57c17c88785c6df1ed840 (diff)
downloadgdb-8d707a12ef51ba5f4c3c6a52532e903da7a56b8b.zip
gdb-8d707a12ef51ba5f4c3c6a52532e903da7a56b8b.tar.gz
gdb-8d707a12ef51ba5f4c3c6a52532e903da7a56b8b.tar.bz2
gdb/18216: displaced step+deliver signal, a thread needs step-over, crash
The problem is that with hardware step targets and displaced stepping, "signal FOO" when stopped at a breakpoint steps the breakpoint instruction at the same time it delivers a signal. This results in tp->stepped_breakpoint set, but no step-resume breakpoint set. When the next stop event arrives, GDB crashes. Irrespective of whether we should do something more/different to step past the breakpoint in this scenario (e.g., PR 18225), it's just wrong to assume there'll be a step-resume breakpoint set (and was not the original intention). gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * infrun.c (process_event_stop_test): Don't assume a step-resume is set if tp->stepped_breakpoint is true. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * gdb.threads/multiple-step-overs.exp: Remove expected eof.
Diffstat (limited to 'bfd/cpu-visium.c')
0 files changed, 0 insertions, 0 deletions