From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint
Date: Sat, 06 Apr 2002 09:21:00 -0000 [thread overview]
Message-ID: <2950-Sat06Apr2002201725+0300-eliz@is.elta.co.il> (raw)
In-Reply-To: <20020406103621.A12359@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 6 Apr 2002 10:36:21 -0500)
> Date: Sat, 6 Apr 2002 10:36:21 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> >
> > Try using a hardware-assisted breakpoint, not a normal breakpoint.
> > Since the latter works by replacing the instruction with a breakpoint
> > opcode, you cannot have a breakpoint and a watchpoint at exactly the
> > same PC value, because doing so replaces the instruction that's
> > supposed to write into some data with the breakpoint opcode.
>
> You can't anyway. You break before an instruction is executed and
> watchpoint before the next instruction is executed, right?
On x86, yes. But the question what does GDB do when the watchpoint
fires remains anyway. GDB should report the watchpoint, not the
breakpoint.
> > If this is limited to stepping, can we check whether we are stepping
> > instead of (or in addition to) the test for whether to ignore
> > breakpoints?
>
> Well, I set the ignore breakpoints flag in the caller only if we are
> stepping.
Isn't it better to make bpstat_stop_status test for stepping directly?
> No. In my original message I made a comment about shlib_event
> breakpoints being a problem. Other breakpoints would to. This is all
> because of the "watchpoint after instr, breakpoint before" thing - we
> would still have to deal with this, or we'd just keep hitting the same
> breakpoint over and over if there was a watchpoint on the next
> instruction.
Sounds like Andrew was right: the decrement-PC logic is screwed.
> But something more fundamental is wrong, because we never
> stop -at all-. I remember something involving initializing the
> watchpoint registers...
I thought that part was solved, but perhaps I'm confused.
next prev parent reply other threads:[~2002-04-06 17:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-02 15:43 Daniel Jacobowitz
2002-04-04 23:38 ` Eli Zaretskii
2002-04-05 7:54 ` Daniel Jacobowitz
2002-04-05 8:45 ` Eli Zaretskii
2002-04-05 9:08 ` Daniel Jacobowitz
2002-04-05 9:55 ` Andrew Cagney
2002-04-05 23:48 ` Eli Zaretskii
2002-04-06 7:36 ` Daniel Jacobowitz
2002-04-06 9:21 ` Eli Zaretskii [this message]
2002-04-06 9:49 ` Daniel Jacobowitz
2002-04-07 9:16 ` Andrew Cagney
2002-04-07 10:03 ` Eli Zaretskii
2002-04-14 14:49 ` Andrew Cagney
2002-04-14 22:07 ` Eli Zaretskii
2002-04-18 18:34 ` Andrew Cagney
2002-04-02 22:18 Michael Elizabeth Chastain
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=2950-Sat06Apr2002201725+0300-eliz@is.elta.co.il \
--to=eliz@is.elta.co.il \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/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