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

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Apr 06, 2002 at 08:17:25PM +0300, Eli Zaretskii wrote:
> > > 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?

The test I'm using is 'trap_expected' - well:
        if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected
            && through_sigtramp_breakpoint == NULL)

It's static to infrun.c, and it describes the precise circumstances in
which we want this behavior.  We can ignore stop_signal (since we only
call bpstat_stop_status if we got a trap), but I have no idea how
through_sigtramp_breakpoint works.  I'd rather calculate this at the
call site than duplicating logic I don't understand very well in
breakpoint.c (which has no business knowing about the internals of
infrun).

> > 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.

I agree.  It's a rat's nest.

> > 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.

So did I, but it does not appear to be the case.  Even access
watchpoints die.  At a guess, in the good case:

insert_watchpoint (addr=8049574, len=4, type=data-read/write):
        CONTROL (DR7): 000f0101          STATUS (DR6): ffff4ff1
        DR0: addr=0x08049574, ref.count=1  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0

In the bad case:

insert_watchpoint (addr=8049574, len=4, type=data-read/write):
        CONTROL (DR7): 000f0101          STATUS (DR6): ffff4ff0
        DR0: addr=0x08049574, ref.count=2  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0

insert_watchpoint (addr=8049574, len=4, type=data-read/write):
        CONTROL (DR7): 000f0101          STATUS (DR6): ffff4ff0
        DR0: addr=0x08049574, ref.count=3  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0

The watchpoint is not removed after program normal exit, and the refcount escalates.

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