This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/18214] New: step over breakpoint and deliver signal, while another thread also needs to step over breakpoint, mishandled on software single-step targets
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 08 Apr 2015 17:57:11 +0000
- Subject: [Bug gdb/18214] New: step over breakpoint and deliver signal, while another thread also needs to step over breakpoint, mishandled on software single-step targets
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18214
Bug ID: 18214
Summary: step over breakpoint and deliver signal, while another
thread also needs to step over breakpoint, mishandled
on software single-step targets
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: palves at redhat dot com
Ref: https://sourceware.org/ml/gdb-patches/2015-04/msg00262.html.
The 'resume' code that detects that we're stepping over a breakpoint
and delivering a signal at the same time:
/* Currently, our software single-step implementation leads to different
results than hardware single-stepping in one situation: when stepping
into delivering a signal which has an associated signal handler,
hardware single-step will stop at the first instruction of the handler,
while software single-step will simply skip execution of the handler.
...
Fortunately, we can at least fix this particular issue. We detect
here the case where we are about to deliver a signal while software
single-stepping with breakpoints removed. In this situation, we
revert the decisions to remove all breakpoints and insert single-
step breakpoints, and instead we install a step-resume breakpoint
at the current address, deliver the signal without stepping, and
once we arrive back at the step-resume breakpoint, actually step
over the breakpoint we originally wanted to step over. */
Doesn't handle the case of another thread also needing to step over a
breakpoint. Because that other thread is just resumed, it'll
immediately re-trap the same breakpoint it had stopped for.
--
You are receiving this mail because:
You are on the CC list for the bug.