This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug breakpoints/19836] New: inserting a watchpoint puts gdb into infinite loop on custom target


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]