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

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Apr 05, 2002 at 07:41:16PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 5 Apr 2002 10:54:16 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > > 
> > > Isn't this a bit ad hoc?  I think the issue of doing TRT when both a
> > > breakpoint and a watchpoint fire for the same instruction needs a more
> > > general solution.  While ignoring breakpoints might be the Right Thing
> > > in this particular case, I wonder what will be TRT in other cases?
> > > 
> > > Did you try to arrange for a normal breakpoint and a watchpoint on the
> > > same instruction, and see what happens in that case, with and without
> > > this patch?
> > 
> > Yes, I did - that's 'watch a.x' in gdb.c++/annota2.exp.  Without the
> > patch it fails on i386-linux, with it it passes.
> 
> ``Fails'' and ``passes'' are in the eyes of the beholder ;-)
> 
> I mean, I'm not even sure what is the ``right'' behavior in this case.
> The annota2.exp test expects something very specific, but is that what
> we want?  Perhaps GDB should say that both breakpoint and watchpoint
> fired instead, or do something else?
>
> I'd suggest to discuss this a bit, because otherwise I don't even know
> what are the criteria for approving or rejecting the patch.  The mere
> fact that the number of testsuite failures goes down is not enough,
> IMHO.

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. 
Barring that, I personally believe that watchpoints should trump
breakpoints; if you stop at a line and have a breakpoint there, you
know you hit the breakpoint.  GDB should tell you if you are stopping
for another reason.

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.  You'll get a trap just before you would have hit the
breakpoint. GDB handles this OK, and does report the watchpoint.  It's
only if we expected a trap (single stepping for instance) that this
does not work.  The current failure is "single step over something
which triggers the watchpoint, landing on something with a breakpoint". 
Without my patch, we detect that we are at an address with a
breakpoint, and don't even try to check our watchpoints.



[In fact, I'm having a great deal of trouble with hardware watchpoints
surviving re-running.  Remember that conversation from several months
ago?

var.c:
int x;

int
main ()
{
  x = 0;
  x = 1;
  x = 2;
  return x;
}


(gdb) watch x
Hardware watchpoint 1: x
(gdb) r
Starting program: /home/drow/debugging/stabrel/foo/foo
Hardware watchpoint 1: x
Hardware watchpoint 1: x
Hardware watchpoint 1: x

Old value = 0
New value = 1
main () at var.c:8
8         x = 2;
(gdb) c
Continuing.
Hardware watchpoint 1: x

Old value = 1
New value = 2
main () at var.c:9
9         return x;
(gdb)
Continuing.

Program exited with code 02.
(gdb) r
Starting program: /home/drow/debugging/stabrel/foo/foo
Hardware watchpoint 1: x
Hardware watchpoint 1: x

Program exited with code 02.


First of all, it stops the instruction after where I would expect. 
That's probably my expectations being off, however.  More important is
the fact that it doesn't stop at all if I re-run.  I'll look into this
(at least a testcase...).]


> 
> > I don't really think it's any more ad-hoc than the trap_expected flag. 
> 
> Perhaps not, but that doesn't mean we should proliferate ad-hoc'ery.
> 
> 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.

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