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/7143] Watchpoint does not trigger when first set


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.


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