diff options
author | Pedro Alves <palves@redhat.com> | 2015-03-04 20:41:15 +0000 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2015-03-04 20:41:15 +0000 |
commit | 1cf4d9513af10d419c71099ae644f07b6724642b (patch) | |
tree | 2c5764e9dfd813f512cab31007e3090f02019273 /gdb/infrun.c | |
parent | be9957b82fa4e09c53521335c2a7dddf6d208309 (diff) | |
download | gdb-1cf4d9513af10d419c71099ae644f07b6724642b.zip gdb-1cf4d9513af10d419c71099ae644f07b6724642b.tar.gz gdb-1cf4d9513af10d419c71099ae644f07b6724642b.tar.bz2 |
Teach GDB about targets that can tell whether a trap is a breakpoint event
The moribund locations heuristics are problematic. This patch teaches
GDB about targets that can reliably tell whether a trap was caused by
a software or hardware breakpoint, and thus don't need moribund
locations, thus bypassing all the problems that mechanism has.
The non-stop-fair-events.exp test is frequently failing currently.
E.g., see https://sourceware.org/ml/gdb-testers/2015-q1/msg03148.html.
The root cause is a fundamental problem with moribund locations. For
example, the stepped_breakpoint logic added by af48d08f breaks in this
case (which is what happens with that test):
- Step thread A, no breakpoint is set at PC.
- The kernel doesn't schedule thread A yet.
- Insert breakpoint at A's PC, for some reason (e.g., a step-resume
breakpoint for thread B).
- Kernel finally schedules thread A.
- thread A's stepped_breakpoint flag is not set, even though it now
stepped a breakpoint instruction.
- adjust_pc_after_break gets the PC wrong, because PC == PREV_PC, but
stepped_breakpoint is not set.
We needed the stepped_breakpoint logic to workaround moribund
locations, because otherwise adjust_pc_after_break could apply an
adjustment when it shouldn't just because there _used_ to be a
breakpoint at PC (a moribund breakpoint location). For example, on
x86, that's wrong if the thread really hasn't executed an int3, but
instead executed some other 1-byte long instruction. Getting the PC
adjustment wrong of course leads to the inferior executing the wrong
instruction.
Other problems with moribund locations are:
- if a true SIGTRAP happens to be raised when the program is
executing the PC that used to have a breakpoint, GDB will assume
that is a trap for a breakpoint that has recently been removed, and
thus we miss reporting the random signal to the user.
- to minimize that, we get rid of moribund location after a while.
That while is defined as just a certain number of events being
processed. That number of events sometimes passes by before a
delayed breakpoint is processed, and GDB confuses the trap for a
random signal, thus reporting the random trap. Once the user
resumes the thread, the program crashes because the PC was not
adjusted...
The fix for all this is to bite the bullet and get rid of heuristics
and instead rely on the target knowing accurately what caused the
SIGTRAP. The target/kernel/stub is in the best position to know what
that, because it can e.g. consult priviledged CPU flags GDB has no
access to, or by knowing which exception vector entry was called when
the instruction trapped, etc. Most debug APIs I've seen to date
report breakpoint hits as a distinct event in some fashion. For
example, on the Linux kernel, whether a breakpoint was executed is
exposed to userspace in the si_code field of the SIGTRAP's siginfo.
On Windows, the debug API reports a EXCEPTION_BREAKPOINT exception
code.
We needed to keep around deleted breakpoints in an on-the-side list
(the moribund locations) for two main reasons:
- Know that a SIGTRAP actually is a delayed event for a hit of a
breakpoint that was removed before the event was processed, and
thus should not be reported as a random signal.
- So we still do the decr_pc_after_break adjustment in that case, so
that the thread is resumed at the correct address.
In the new model, if GDB processes an event the target tells is a
breakpoint trap, and GDB doesn't find the corresponding breakpoint in
its breakpoint tables, it means that event is a delayed event for a
breakpoint that has since been removed, and thus the event should be
ignored.
For the decr_pc_after_after issue, it ends up being much simpler that
on targets that can reliably tell whether a breakpoint trapped, for
the breakpoint trap to present the PC already adjusted. Proper
multi-threading support already implies that targets needs to be doing
decr_pc_after_break adjustment themselves, otherwise for example, in
all-stop if two threads hit a breakpoint simultaneously, and the user
does "info threads", he'll see the non-event thread that hit the
breakpoint stopped at the wrong PC.
This way (target adjusts) also ends up eliminating the need for some
awkward re-incrementing of the PC in the record-full and Linux targets
that we do today, and the need for the target_decr_pc_after_break
hook.
If the target always adjusts, then there's a case where GDB needs to
re-increment the PC. Say, on x86, an "int3" instruction that was
explicitly written in the program traps. In this case, GDB should
report a random SIGTRAP signal to the user, with the PC pointing at
the instruction past the int3, just like if GDB was not debugging the
program. The user may well decide to pass the SIGTRAP to the program
because the program being debugged has a SIGTRAP handler that handles
its own breakpoints, and expects the PC to be unadjusted.
Tested on x86-64 Fedora 20.
gdb/ChangeLog:
2015-03-04 Pedro Alves <palves@redhat.com>
* breakpoint.c (need_moribund_for_location_type): New function.
(bpstat_stop_status): Don't skipping checking moribund locations
of breakpoint types which the target tell caused a stop.
(program_breakpoint_here_p): New function, factored out from ...
(bp_loc_is_permanent): ... this.
(update_global_location_list): Don't create a moribund location if
the target supports reporting stops of the type of the removed
breakpoint.
* breakpoint.h (program_breakpoint_here_p): New declaration.
* infrun.c (adjust_pc_after_break): Return early if the target has
already adjusted the PC. Add comments.
(handle_signal_stop): If nothing explains a signal, and the target
tells us the stop was caused by a software breakpoint, check if
there's a breakpoint instruction in the memory. If so, adjust the
PC before presenting the stop to the user. Otherwise, ignore the
trap. If nothing explains a signal, and the target tells us the
stop was caused by a hardware breakpoint, ignore the trap.
* target.h (struct target_ops) <to_stopped_by_sw_breakpoint,
to_supports_stopped_by_sw_breakpoint, to_stopped_by_hw_breakpoint,
to_supports_stopped_by_hw_breakpoint>: New fields.
(target_stopped_by_sw_breakpoint)
(target_supports_stopped_by_sw_breakpoint)
(target_stopped_by_hw_breakpoint)
(target_supports_stopped_by_hw_breakpoint): Define.
* target-delegates.c: Regenerate.
Diffstat (limited to 'gdb/infrun.c')
-rw-r--r-- | gdb/infrun.c | 70 |
1 files changed, 69 insertions, 1 deletions
diff --git a/gdb/infrun.c b/gdb/infrun.c index abfeeee..8d3a9bf 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -3468,6 +3468,18 @@ adjust_pc_after_break (struct execution_control_state *ecs) if (execution_direction == EXEC_REVERSE) return; + /* If the target can tell whether the thread hit a SW breakpoint, + trust it. Targets that can tell also adjust the PC + themselves. */ + if (target_supports_stopped_by_sw_breakpoint ()) + return; + + /* Note that relying on whether a breakpoint is planted in memory to + determine this can fail. E.g,. the breakpoint could have been + removed since. Or the thread could have been told to step an + instruction the size of a breakpoint instruction, and only + _after_ was a breakpoint inserted at its address. */ + /* If this target does not decrement the PC after breakpoints, then we have nothing to do. */ regcache = get_thread_regcache (ecs->ptid); @@ -3483,6 +3495,11 @@ adjust_pc_after_break (struct execution_control_state *ecs) breakpoint would be. */ breakpoint_pc = regcache_read_pc (regcache) - decr_pc; + /* If the target can't tell whether a software breakpoint triggered, + fallback to figuring it out based on breakpoints we think were + inserted in the target, and on whether the thread was stepped or + continued. */ + /* Check whether there actually is a software breakpoint inserted at that location. @@ -3490,7 +3507,10 @@ adjust_pc_after_break (struct execution_control_state *ecs) removed a breakpoint, but stop events for that breakpoint were already queued and arrive later. To suppress those spurious SIGTRAPs, we keep a list of such breakpoint locations for a bit, - and retire them after a number of stop events are reported. */ + and retire them after a number of stop events are reported. Note + this is an heuristic and can thus get confused. The real fix is + to get the "stopped by SW BP and needs adjustment" info out of + the target/kernel (and thus never reach here; see above). */ if (software_breakpoint_inserted_here_p (aspace, breakpoint_pc) || (non_stop && moribund_breakpoint_here_p (aspace, breakpoint_pc))) { @@ -4505,6 +4525,54 @@ handle_signal_stop (struct execution_control_state *ecs) = !bpstat_explains_signal (ecs->event_thread->control.stop_bpstat, ecs->event_thread->suspend.stop_signal); + /* Maybe this was a trap for a software breakpoint that has since + been removed. */ + if (random_signal && target_stopped_by_sw_breakpoint ()) + { + if (program_breakpoint_here_p (gdbarch, stop_pc)) + { + struct regcache *regcache; + int decr_pc; + + /* Re-adjust PC to what the program would see if GDB was not + debugging it. */ + regcache = get_thread_regcache (ecs->event_thread->ptid); + decr_pc = target_decr_pc_after_break (gdbarch); + if (decr_pc != 0) + { + struct cleanup *old_cleanups = make_cleanup (null_cleanup, NULL); + + if (record_full_is_used ()) + record_full_gdb_operation_disable_set (); + + regcache_write_pc (regcache, stop_pc + decr_pc); + + do_cleanups (old_cleanups); + } + } + else + { + /* A delayed software breakpoint event. Ignore the trap. */ + if (debug_infrun) + fprintf_unfiltered (gdb_stdlog, + "infrun: delayed software breakpoint " + "trap, ignoring\n"); + random_signal = 0; + } + } + + /* Maybe this was a trap for a hardware breakpoint/watchpoint that + has since been removed. */ + if (random_signal && target_stopped_by_hw_breakpoint ()) + { + /* A delayed hardware breakpoint event. Ignore the trap. */ + if (debug_infrun) + fprintf_unfiltered (gdb_stdlog, + "infrun: delayed hardware breakpoint/watchpoint " + "trap, ignoring\n"); + random_signal = 0; + } + /* If not, perhaps stepping/nexting can. */ if (random_signal) random_signal = !(ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP |