This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/19836] New: inserting a watchpoint puts gdb into infinite loop on custom target
- From: "branko.drevensek at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 17 Mar 2016 17:10:32 +0000
- Subject: [Bug breakpoints/19836] New: inserting a watchpoint puts gdb into infinite loop on custom target
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=19836
Bug ID: 19836
Summary: inserting a watchpoint puts gdb into infinite loop on
custom target
Product: gdb
Version: 7.11
Status: NEW
Severity: minor
Priority: P2
Component: breakpoints
Assignee: unassigned at sourceware dot org
Reporter: branko.drevensek at gmail dot com
Target Milestone: ---
First note, that this refers to our custom gdb port, but possible upstream
issue.
We bumped into this while updating our port from 7.8, where it everything
worked as expected. Since 7.9.1 (and possibly 7.9) it does not.
Details:
a) This is custom remote target.
b) We have steppable (to_have_steppable_watchpoint = 1) non-continuable
(to_have_continuable_watchpoint = 0) watchpoints.
c) We have a workaround (setting watchpoints to non-continuable), so this is
not critical for us, but might save someone else some time.
What happens in 7.11 (and 7.9.1 and 7.10) is:
0) Target is connected, set up, "write" watchpoint is set up. Target is
continued.
1) Watchpoint gets hit, which stalls the target.
status is set to TARGET_WAITKIND_STOPPED, signal is set to GDB_SIGNAL_TRAP.
2) To_watchpoint_triggered properly lets generic code know, watchpoint has
triggered and is within range of one of watchpoints.
3) Then in proceeds to this code in handle_signal_stop:
ecs->event_thread->stepping_over_watchpoint = 1;
keep_going (ecs);
and into keep_going_pass_signal:
step_what = thread_still_needs_step_over (ecs->event_thread);
In thread_still_needs_step_over result gets set to 0 due to this statement:
if (tp->stepping_over_watchpoint
&& !target_have_steppable_watchpoint)
what |= STEP_OVER_WATCHPOINT;
as target_have_steppable_watchpoint is set to 1 on our target.
If I understand correctly, this code determines, it does not have to remove
breakpoints or watchpoints.
ecs->event_thread->control.trap_expected is therefor set to 0.
(* Here I would expect trap_expected to be set to 1. *)
Code then proceeds to resume, which sets step to 0 in:
step = currently_stepping (tp);
Which eventually leads to:
4)
do_target_resume (resume_ptid, step, sig);
being called with step=0.
5) And we're back at 1 (causing in infinite loop).
Infrun debug printouts for this:
infrun: target_wait (-1.0.0, status) =
infrun: 1.0.1 [Thread <main>],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x215
infrun: stopped by watchpoint
infrun: stopped data address = 0xfff4
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread <main>] at 0x215
infrun: prepare_to_wait
CPU stalled.
infrun: target_wait (-1.0.0, status) =
infrun: 1.0.1 [Thread <main>],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x22e
infrun: stopped by watchpoint
infrun: stopped data address = 0xfff4
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread <main>] at 0x22e
infrun: prepare_to_wait
And this last part repeats indefinitely (watchpoint at 0x22e being hit again
and again, but never reported to user).
--
You are receiving this mail because:
You are on the CC list for the bug.