Re: [RFA] Fix watchpoints when stepping over a breakpoint

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Apr 06, 2002 at 10:41:45AM +0300, Eli Zaretskii wrote:
> > Date: Fri, 5 Apr 2002 12:08:51 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > I think GDB ought to show that both the breakpoint and watchpoint have
> > fired.  At least, that's the behavior I would expect. I also thought
> > that was what it would do, but I can't seem to make that happen. 
> 
> 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?

> > Also bear in mind that if you have this sequence:
> > - write to x
> > - other instruction    <--- breakpoint here
> > You will stop based on the watchpoint, because the watchpoint happens
> > first.
> 
> That's okay, since the instruction that writes to x is before the
> breakpoint.  In this case, I'd expect to have a watchpoint, then,
> when I continue, I'd expect to hit the breakpoint.
> 
> > It's only if we expected a trap (single stepping for instance) that
> > this does not work.
> 
> 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.

> > Without my patch, we detect that we are at an address with a
> > breakpoint, and don't even try to check our watchpoints.
> 
> If we change GDB to report both the breakpoint and watchpoint, the
> problem would go away, no?

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.

> > [In fact, I'm having a great deal of trouble with hardware watchpoints
> > surviving re-running.  Remember that conversation from several months
> > ago?
> 
> Yes.  This is definitely wrong behavior, IMHO.  IIRC, the problem is
> that GDB doesn't initialize the ``old value'' correctly on the rerun,
> and so when the watchpoint hits, it thinks it's a false positive,
> because watchpoints are suppressed if the watched value doesn't
> change.

That too.  But something more fundamental is wrong, because we never
stop -at all-.  I remember something involving initializing the
watchpoint registers...

> > > More importantly, an introduction of a general-purpose mechanism to
> > > ignore breakpoints is something that I consider to be dangerous,
> > > because it is no longer limited to special situations such as
> > > single-stepping.
> > 
> > Well, we could just as easily call the flag "single_stepping"...  That
> > would probably limit abuse.
> 
> If all else fails, at least that, yes.
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer