From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
Subject: Re: MI: reporting of multiple breakpoints
Date: Fri, 17 Feb 2006 20:08:00 -0000 [thread overview]
Message-ID: <20060217200558.GA30145@nevyn.them.org> (raw)
In-Reply-To: <ufymhhi81.fsf@gnu.org>
On Fri, Feb 17, 2006 at 09:56:46PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:44:26 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> >
> > There are two events in hardware, yes - but "GDB will always see these
> > two as separate events" is not accurate. Suppose we've got an
> > instruction at foo+0x10 that stores to a watched address and at
> > foo+0x16 that has a breakpoint set on it. The watchpoint will trigger,
> > stopping GDB at foo+0x16. At this point, we were stopped by the
> > watchpoint, but we'll never hit the breakpoint - if the user "continue"s,
> > GDB will politely step around the breakpoint. In effect, we've
> > hit the watchpoint and breakpoint simultaneously, and IMO it would
> > be appropriate to let the user know about both of them.
>
> Why do we step around the breakpoint? As long as we do that, the
> breakpoint never happened, and we don't need to announce it. If we
> _want_ to announce it, we should stop stepping around it, IMHO.
All this long predates me, you understand. I can only give you my
interpretation, not a real reason. But the status quo seems reasonable
enough to me.
Consider a store which causes two user-placed watchpoints to trigger -
this is pretty easy since there is a non-trivial mapping between user
watchpoints and watched values. We want to report both watchpoints.
But we were, physically, only stopped for one of them.
It's the same thing with breakpoints. A breakpoint is "stop the
program when you reach address FOO". We've reached address FOO; the
fact that something _else_ caused us to stop at the same time seems
only marginally relevant.
We step around it because we want to announce the breakpoint when
we first reach the relevant PC; if we're at FOO and say continue
then normally we won't hit the breakpoint at FOO, because after
hitting that breakpoint we present $pc == FOO to the user.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-02-17 20:06 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 15:32 Vladimir Prus
2006-02-17 15:48 ` Daniel Jacobowitz
2006-02-17 16:04 ` Vladimir Prus
2006-02-17 18:59 ` Daniel Jacobowitz
2006-02-17 19:04 ` Daniel Jacobowitz
2006-02-17 19:52 ` Eli Zaretskii
2006-02-17 19:54 ` Daniel Jacobowitz
2006-02-17 19:59 ` Eli Zaretskii
2006-02-17 20:06 ` Paul Koning
2006-02-17 20:08 ` Daniel Jacobowitz
2006-02-17 20:16 ` Eli Zaretskii
2006-02-17 20:19 ` Daniel Jacobowitz
2006-02-17 20:18 ` Paul Koning
2006-02-17 20:24 ` Daniel Jacobowitz
2006-02-17 21:37 ` Paul Koning
2006-02-17 21:43 ` Daniel Jacobowitz
2006-02-17 21:56 ` Paul Koning
2006-02-17 22:12 ` Daniel Jacobowitz
2006-02-18 9:54 ` Paul Koning
2006-02-18 10:56 ` Daniel Jacobowitz
2006-02-18 15:47 ` Eli Zaretskii
2006-02-18 15:28 ` Eli Zaretskii
2006-02-18 17:28 ` Daniel Jacobowitz
2006-02-18 17:42 ` Eli Zaretskii
2006-02-18 17:50 ` Daniel Jacobowitz
2006-02-18 18:33 ` Eli Zaretskii
2006-02-19 18:20 ` Paul Koning
2006-02-19 18:31 ` Daniel Jacobowitz
2006-02-19 18:44 ` Robert Dewar
2006-02-20 3:16 ` Eli Zaretskii
2006-02-18 11:39 ` Eli Zaretskii
2006-02-19 18:19 ` Paul Koning
2006-02-19 18:38 ` Daniel Jacobowitz
2006-02-19 18:54 ` Paul Koning
2006-02-19 19:05 ` Robert Dewar
2006-02-19 19:30 ` Paul Koning
2006-02-19 19:52 ` Daniel Jacobowitz
2006-02-19 19:57 ` Paul Koning
2006-02-19 21:55 ` Eli Zaretskii
2006-02-20 4:33 ` Daniel Jacobowitz
2006-02-20 7:25 ` Eli Zaretskii
2006-02-20 18:20 ` Daniel Jacobowitz
2006-02-17 20:14 ` Eli Zaretskii
2006-02-17 20:08 ` Daniel Jacobowitz [this message]
2006-02-17 20:22 ` Eli Zaretskii
2006-02-17 20:31 ` Daniel Jacobowitz
2006-02-17 20:32 ` Eli Zaretskii
2006-02-17 20:41 ` Daniel Jacobowitz
2006-02-17 20:02 ` Eli Zaretskii
2006-02-17 20:15 ` Daniel Jacobowitz
2006-02-17 19:36 ` Eli Zaretskii
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=20060217200558.GA30145@nevyn.them.org \
--to=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/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