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 19:54:00 -0000 [thread overview]
Message-ID: <20060217194426.GA28988@nevyn.them.org> (raw)
In-Reply-To: <ulkw9hj1y.fsf@gnu.org>
On Fri, Feb 17, 2006 at 09:38:49PM +0200, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 18:47:59 +0300
> >
> > > The CLI does the same thing; so does the core of GDB, unsurprisingly.
> >
> > For ordinary breakpoints, yes. For watchpoints, not quite:
>
> That's because breakpoint.c treats breakpoints and watchpoints
> differently in this regard, I don't know why. You will see that
> print_it_typical returns PRINT_SRC_AND_LOC for breakpoints, but
> PRINT_UNKNOWN for watchpoints.
>
> Does anyone know why we return PRINT_SRC_AND_LOC for breakpoints?
That's how we get the source line printed when we stop, isn't it?
I'd ask the opposite question, but I suspect the use of PRINT_UNKNOWN
has something to do with how the old/new values get printed out.
> > I did not test more complex combinations, like mix of watchpoints
> > and breakpoints that trigger on the same line.
>
> I don't think you will find anything interesting by mixing those, at
> least not on x86. Setting a breakpoint replaces the original
> instruction by a special opcode, so the original instruction cannot
> run and trigger the watchpoint. After the breakpoint is hit, GDB
> restores the original instruction, and then the watchpoint triggers.
> So GDB will always see these two as separate events, each one stopping
> the inferior in its own due time.
>
> Similar things happen if you use hbreak: the x86 architecture causes
> the hardware breakpoint to break _before_ the instruction runs, but a
> watchpoint breaks _after_ the instruction runs. So again there are
> two separate events.
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.
What do you think?
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-02-17 19:44 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 [this message]
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
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=20060217194426.GA28988@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