This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/7143] Watchpoint does not trigger when first set
- From: "brobecker at adacore dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 29 May 2014 17:47:52 +0000
- Subject: [Bug breakpoints/7143] Watchpoint does not trigger when first set
- Auto-submitted: auto-generated
- References: <bug-7143-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=7143
--- Comment #15 from brobecker at adacore dot com ---
> Odd. It's as if the breakpoint at 0x10000a28 never got inserted at all.
I am on it, but just to keep you entertained... :-)
It appears to be exactly what's going on. I am wondering if that may be
related to the fact that we have a user breakpoint at the same address
as one of the SSS breakpoints. That's all a guess, since I haven't
really looked into details at which breakpoint insertions correspond
to what. But notice how we insert the breakpoint at 0x10000a28 twice?
(gdb) c
>>> First, we insert the user breakpoints (the second one is an internal
>>> breakpoint on __pthread_init). The first user breakpoint is not
>>> inserted as we need to step out of it first.
target_insert_breakpoint (0x0000000010000a28, xxx) = 0
target_insert_breakpoint (0x00000000d03f3800, xxx) = 0
>>> Then we proceed with the step-out-of-breakpoint...
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread
[process 15335610] at 0x10000a24
>>> That's when we insert the SSS breakpoints...
target_insert_breakpoint (0x0000000010000a28, xxx) = 0
target_insert_breakpoint (0x00000000100009ac, xxx) = 0
>>> ... then let the inferior resume...
target_resume (15335610, continue, 0)
infrun: wait_for_inferior ()
target_wait (-1, status, options={}) = 15335610, status->kind = stopped,
signal = GDB_SIGNAL_TRAP
infrun: target_wait (-1, status) =
infrun: 15335610 [process 15335610],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x100009ac
>>> At this point, we stopped at the second SSS breakpoint...
target_stopped_by_watchpoint () = 0
>>> That must be us removing the SSS breakpoints...
target_remove_breakpoint (0x0000000010000a28, xxx) = 0
target_remove_breakpoint (0x00000000100009ac, xxx) = 0
target_stopped_by_watchpoint () = 0
>>> We find that we're not done, so we resume....
infrun: no stepping, continue
>>> And thus insert the userr breakpoints again, except we're not
>>> inserting the second breakpoint?!? I bet this is because we think
>>> it's still inserted, but in fact it got removed by the SSS bp
>>> removal earlier.
target_insert_breakpoint (0x0000000010000a24, xxx) = 0
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 15335610] at 0x100009ac
target_resume (-1, continue, 0)
infrun: prepare_to_wait
target_wait (-1, status, options={}) = 15335610, status->kind = exited,
status = 2
--
You are receiving this mail because:
You are on the CC list for the bug.