public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "brobecker at adacore dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug breakpoints/7143] Watchpoint does not trigger when first set Date: Thu, 29 May 2014 17:47:00 -0000 [thread overview] Message-ID: <bug-7143-4717-5GxglRcIAH@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-7143-4717@http.sourceware.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.
next prev parent reply other threads:[~2014-05-29 17:47 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-7143-4717@http.sourceware.org/bugzilla/> 2012-01-25 16:29 ` tromey at redhat dot com 2012-01-25 16:34 ` tromey at redhat dot com 2012-01-25 16:58 ` palves at redhat dot com 2012-03-30 13:46 ` eager at eagercon dot com 2012-09-25 21:09 ` palves at redhat dot com 2014-02-24 17:23 ` palves at redhat dot com 2014-03-20 13:49 ` cvs-commit at gcc dot gnu.org 2014-03-20 13:53 ` palves at redhat dot com 2014-05-20 18:02 ` cvs-commit at gcc dot gnu.org 2014-05-29 13:28 ` brobecker at gnat dot com 2014-05-29 15:01 ` palves at redhat dot com 2014-05-29 15:02 ` palves at redhat dot com 2014-05-29 17:47 ` brobecker at adacore dot com [this message] 2014-05-29 18:04 ` palves at redhat dot com 2014-05-29 18:35 ` brobecker at adacore dot com 2014-05-29 22:22 ` palves at redhat dot com 2014-05-30 16:09 ` palves at redhat dot com 2014-05-30 16:21 ` brobecker at adacore dot com 2014-08-19 17:19 ` cvs-commit at gcc dot gnu.org [not found] <20010311215800.7143.chastain@redhat.com> 2009-01-09 16:48 ` naaaag at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-7143-4717-5GxglRcIAH@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).