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.


  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: link
Be 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).