diff options
| author | Pedro Alves <palves@redhat.com> | 2015-04-10 10:36:23 +0100 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2015-04-10 10:36:23 +0100 |
| commit | 8d707a12ef51ba5f4c3c6a52532e903da7a56b8b (patch) | |
| tree | 37c565150854b4dfaee0f9cb7968784d397b6396 /gdb/objfiles.h | |
| parent | ef713951c571c8490ca57c17c88785c6df1ed840 (diff) | |
| download | gdb-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 'gdb/objfiles.h')
0 files changed, 0 insertions, 0 deletions