MI: reporting of multiple breakpoints

MI: reporting of multiple breakpoints

[Vladimir Prus]

Hello!
It seems that for stop on multiple breakpoints, MI reports only one:

    (gdb)
    -break-insert main
    ^done,bkpt={number="1",type="breakpoint".....
    (gdb)
    -break-insert main
    ^done,bkpt={number="2",type="breakpoint"......
    (gdb)
    -exec-run
    ^running
    (gdb)
   *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={...}

Is this a bug, or by design?


- Volodya

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 06:01:13PM +0300, Vladimir Prus wrote:
> 
> Hello!
> It seems that for stop on multiple breakpoints, MI reports only one:
> 
>     (gdb)
>     -break-insert main
>     ^done,bkpt={number="1",type="breakpoint".....
>     (gdb)
>     -break-insert main
>     ^done,bkpt={number="2",type="breakpoint"......
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>    *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={...}
> 
> Is this a bug, or by design?

The CLI does the same thing; so does the core of GDB, unsurprisingly.
It's not entirely obvious what ought to happen.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Feb 17, 2006 at 06:01:13PM +0300, Vladimir Prus wrote:
>> 
>> Hello!
>> It seems that for stop on multiple breakpoints, MI reports only one:
>> 
>>     (gdb)
>>     -break-insert main
>>     ^done,bkpt={number="1",type="breakpoint".....
>>     (gdb)
>>     -break-insert main
>>     ^done,bkpt={number="2",type="breakpoint"......
>>     (gdb)
>>     -exec-run
>>     ^running
>>     (gdb)
>>    *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={...}
>> 
>> Is this a bug, or by design?
> 
> The CLI does the same thing; so does the core of GDB, unsurprisingly.

For ordinary breakpoints, yes. For watchpoints, not quite:

    (gdb) watch p1
    Hardware watchpoint 3: p1
    (gdb) watch p1
    Hardware watchpoint 4: p1
    (gdb) c
    Continuing.
    Hardware watchpoint 3: p1
    
    Old value = (int *) 0x0
    New value = (int *) 0x8049994
    Hardware watchpoint 4: p1
    
    Old value = (int *) 0x0
    New value = (int *) 0x8049994
    main () at print_pointers.cpp:27
    27          B* p2 = (B*)0x12345678;

while in MI we get:

    -break-watch p1
    ^done,wpt={number="2",exp="p1"}
    (gdb)
    -break-watch p2
    ^done,wpt={number="3",exp="p2"}
    (gdb)
    -exec-continue
    ^running
    (gdb)
    *stopped,reason="watchpoint-trigger",
    wpt={number="2",exp="p1"},
    value={old="(int *) 0x0",new="(int *) 0x8049994"},
    thread-id="1",frame={...}

CLI reports two watchpoints, and MI reports just one. I did not test more
complex combinations, like mix of watchpoints and breakpoints that trigger
on the same line.


> It's not entirely obvious what ought to happen.

Well, all breakpoints which stop conditions are satisfied should be
reported, I guess.

- Volodya

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 06:47:59PM +0300, Vladimir Prus wrote:
> CLI reports two watchpoints, and MI reports just one. I did not test more
> complex combinations, like mix of watchpoints and breakpoints that trigger
> on the same line.

More complex combinations will provide more interesting messes.  I
believe it's only watchpoints that "work".

> > It's not entirely obvious what ought to happen.
> 
> Well, all breakpoints which stop conditions are satisfied should be
> reported, I guess.

I think this is right but it may be a bit of trouble to implement.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 06:47:59PM +0300, Vladimir Prus wrote:
> CLI reports two watchpoints, and MI reports just one. I did not test more
> complex combinations, like mix of watchpoints and breakpoints that trigger
> on the same line.

More complex combinations will provide more interesting messes.  I
believe it's only watchpoints that "work".

> > It's not entirely obvious what ought to happen.
> 
> Well, all breakpoints which stop conditions are satisfied should be
> reported, I guess.

I think this is right but it may be a bit of trouble to implement.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

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

> CLI reports two watchpoints, and MI reports just one.

Both should report all of them, IMHO.

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

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

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

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 14:44:26 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> 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.

Why do we step around the breakpoint?  As long as we do that, the
breakpoint never happened, and we don't need to announce it.  If we
_want_ to announce it, we should stop stepping around it, IMHO.

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 >> Date: Fri, 17 Feb 2006 14:44:26 -0500 From: Daniel Jacobowitz
 >> <drow@false.org> Cc: Vladimir Prus <ghost@cs.msu.su>,
 >> gdb@sources.redhat.com
 >> 
 >> 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.

 Eli> Why do we step around the breakpoint?  As long as we do that,
 Eli> the breakpoint never happened, and we don't need to announce it.
 Eli> If we _want_ to announce it, we should stop stepping around it,
 Eli> IMHO.

I think it is wrong to step around a breakpoint that's set at a
different instruction than one that triggers a watchpoint.  For
example, suppose I'm monitoring a variable by setting a watchpoint,
and setting up a command sequence to print an expression and
continue.  Separate from that, I want the program to break at line x.

It is a bad thing for the break at x to fail due to the bad luck of
having a watch exception at the preceding instruction.  If the two
stops happened to be the SAME instruction, then you have plausible
deniability.  But not if they are different instructions.

	      paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 03:01:50PM -0500, Paul Koning wrote:
> I think it is wrong to step around a breakpoint that's set at a
> different instruction than one that triggers a watchpoint.  For
> example, suppose I'm monitoring a variable by setting a watchpoint,
> and setting up a command sequence to print an expression and
> continue.  Separate from that, I want the program to break at line x.
> 
> It is a bad thing for the break at x to fail due to the bad luck of
> having a watch exception at the preceding instruction.  If the two
> stops happened to be the SAME instruction, then you have plausible
> deniability.  But not if they are different instructions.

This just doesn't scale.  Now the user places two breakpoints at foo
(via complicated scripts, say) and one of them has continue in its
commands list.  The user could make the exact same argument to complain
that we "didn't stop".

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 15:07:12 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
> 
> This just doesn't scale.  Now the user places two breakpoints at foo
> (via complicated scripts, say) and one of them has continue in its
> commands list.  The user could make the exact same argument to complain
> that we "didn't stop".

There's no end to this.  A breakpoint could have in its comand list a
command to delete the other breakpoint at this location; now what?

GDB gives users enough rope to hang themselves, so I don't think we
should consider situations when they do.  We should, however, do
reasonable things for simple situations where users expect us to do
those reasonable things, and there are no complications to do what
they expect.  I think.

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 10:14:27PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 15:07:12 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
> > 
> > This just doesn't scale.  Now the user places two breakpoints at foo
> > (via complicated scripts, say) and one of them has continue in its
> > commands list.  The user could make the exact same argument to complain
> > that we "didn't stop".
> 
> There's no end to this.  A breakpoint could have in its comand list a
> command to delete the other breakpoint at this location; now what?
> 
> GDB gives users enough rope to hang themselves, so I don't think we
> should consider situations when they do.  We should, however, do
> reasonable things for simple situations where users expect us to do
> those reasonable things, and there are no complications to do what
> they expect.  I think.

Sure, but we disagree on whether the situation Paul described is
"reasonable" and "simple".  I really don't think it is.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Fri, Feb 17, 2006 at 03:01:50PM -0500, Paul Koning wrote:
 >> I think it is wrong to step around a breakpoint that's set at a
 >> different instruction than one that triggers a watchpoint.  For
 >> example, suppose I'm monitoring a variable by setting a
 >> watchpoint, and setting up a command sequence to print an
 >> expression and continue.  Separate from that, I want the program
 >> to break at line x.
 >> 
 >> It is a bad thing for the break at x to fail due to the bad luck
 >> of having a watch exception at the preceding instruction.  If the
 >> two stops happened to be the SAME instruction, then you have
 >> plausible deniability.  But not if they are different
 >> instructions.

 Daniel> This just doesn't scale.  Now the user places two breakpoints
 Daniel> at foo (via complicated scripts, say) and one of them has
 Daniel> continue in its commands list.  The user could make the exact
 Daniel> same argument to complain that we "didn't stop".

That's not the same case.  I was going to say that both stops should
be reported even if they are at the SAME address, then decided against
that, as you did.

But in the case we're talking about, you could have this source code:

421    foo=1;
422    bar=2;

I set a breakpoint on line 422, and a watchpoint on "foo".  Clearly
those are very different -- line 422 doesn't touch foo, and the line
that touches foo isn't line 422.  GDB should not confuse those two
things.  If the hardware or GDB advances the PC across the watched
instruction, that's very well but that doesn't mean GDB should believe
the stop point is the instruction after.  The stop point is the store
into foo, which isn't line 422.

     paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 03:16:15PM -0500, Paul Koning wrote:
> That's not the same case.  I was going to say that both stops should
> be reported even if they are at the SAME address, then decided against
> that, as you did.
> 
> But in the case we're talking about, you could have this source code:
> 
> 421    foo=1;
> 422    bar=2;
> 
> I set a breakpoint on line 422, and a watchpoint on "foo".  Clearly
> those are very different -- line 422 doesn't touch foo, and the line
> that touches foo isn't line 422.  GDB should not confuse those two
> things.  If the hardware or GDB advances the PC across the watched
> instruction, that's very well but that doesn't mean GDB should believe
> the stop point is the instruction after.  The stop point is the store
> into foo, which isn't line 422.

So?

The user does "set $var = $pc" after hitting the breakpoint at bar.
Then later they do jump *$var.  They have every right (IMO) to expect
that they are, once again, after the breakpoint at line 422, and that
it won't be hit again - and even though you could make a good argument
for the opposite case, this is how GDB has behaved for a long while.
I think you'll encounter just as manage strange cases if you reverse
it.

Another way to think about it, if this helps.  Right now you will not
hit a GDB-requested event after "step" or "continue" without executing
at least one instruction.  You might be interrupted (by a trap
instruction, an async signal, et cetera).  But GDB will do its level
best to step when you ask for a step, not hit a breakpoint that
you've already noticed.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Fri, Feb 17, 2006 at 03:16:15PM -0500, Paul Koning wrote:
 >> That's not the same case.  I was going to say that both stops
 >> should be reported even if they are at the SAME address, then
 >> decided against that, as you did.
 >> 
 >> But in the case we're talking about, you could have this source
 >> code:
 >> 
 >> 421 foo=1; 
 >> 422 bar=2;
 >> 
 >> I set a breakpoint on line 422, and a watchpoint on "foo".
 >> Clearly those are very different -- line 422 doesn't touch foo,
 >> and the line that touches foo isn't line 422.  GDB should not
 >> confuse those two things.  If the hardware or GDB advances the PC
 >> across the watched instruction, that's very well but that doesn't
 >> mean GDB should believe the stop point is the instruction after.
 >> The stop point is the store into foo, which isn't line 422.

 Daniel> So?

 Daniel> The user does "set $var = $pc" after hitting the breakpoint
 Daniel> at bar.  Then later they do jump *$var.  They have every
 Daniel> right (IMO) to expect that they are, once again, after the
 Daniel> breakpoint at line 422, and that it won't be hit again - and
 Daniel> even though you could make a good argument for the opposite
 Daniel> case, this is how GDB has behaved for a long while.  I think
 Daniel> you'll encounter just as manage strange cases if you reverse
 Daniel> it.

 Daniel> Another way to think about it, if this helps.  Right now you
 Daniel> will not hit a GDB-requested event after "step" or "continue"
 Daniel> without executing at least one instruction.  You might be
 Daniel> interrupted (by a trap instruction, an async signal, et
 Daniel> cetera).  But GDB will do its level best to step when you ask
 Daniel> for a step, not hit a breakpoint that you've already noticed.

Exactly my point.  The case you're talking about is the opposite of
the one I was talking about.

The program runs, executes the store into foo.  GDB should report
hitting the watchpoint on foo, and should NOT report hitting the
breakpoint at 422.

User says "step".  We execute one instruction, which is the breakpoint
trap, and report that as the breakpoint at line 422.  User is happy.

Maybe I'm messing up the discussion by being confused about what the
problem is that started the thread.  I thought what I heard is: the
watchpoint traps with the PC pointing *after* the store, i.e., it
points at the trap instruction, so it looks like two simultaneous
stops.  

My point is that this is not correct reasoning: the watchpoint stop is
at PC-instruction_size, which is in line 421 (last instruction of 421)
and clearly different from line 422.  Yes, the hardware reports PC,
not PC-instruction_size, but that's GDB's job to sort out, not the
user's.

	paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 04:14:42PM -0500, Paul Koning wrote:
>  Daniel> So?
> 
>  Daniel> The user does "set $var = $pc" after hitting the breakpoint
>  Daniel> at bar.  Then later they do jump *$var.  They have every
>  Daniel> right (IMO) to expect that they are, once again, after the
>  Daniel> breakpoint at line 422, and that it won't be hit again - and
>  Daniel> even though you could make a good argument for the opposite
>  Daniel> case, this is how GDB has behaved for a long while.  I think
>  Daniel> you'll encounter just as manage strange cases if you reverse
>  Daniel> it.
> 
>  Daniel> Another way to think about it, if this helps.  Right now you
>  Daniel> will not hit a GDB-requested event after "step" or "continue"
>  Daniel> without executing at least one instruction.  You might be
>  Daniel> interrupted (by a trap instruction, an async signal, et
>  Daniel> cetera).  But GDB will do its level best to step when you ask
>  Daniel> for a step, not hit a breakpoint that you've already noticed.
> 
> Exactly my point.  The case you're talking about is the opposite of
> the one I was talking about.
> 
> The program runs, executes the store into foo.  GDB should report
> hitting the watchpoint on foo, and should NOT report hitting the
> breakpoint at 422.
> 
> User says "step".  We execute one instruction, which is the breakpoint
> trap, and report that as the breakpoint at line 422.  User is happy.

No, this is not the opposite of what I described; could you explain why
you think it is?  It's indistinguishable from what I described.  If we
set the PC to the PC of the breakpoint, we assume we are past (have
already hit) the breakpoint.  Therefore when we're stopped by a
watchpoint at the PC of a breakpoint, it's sensible to treat this
situation to the user as if we have already hit the breakpoint.

Try single-stepping up to a breakpoint if that clarifies things:

4       main (int argc, char **argv)
5       {
6         printf ("Hello world\n");
7         return 0;
8       }
(gdb) b 7
Breakpoint 2 at 0x80483a4: file debugging/printf.c, line 7.
(gdb) s
Hello world

Breakpoint 2, main (argc=1, argv=0xbfe9b154) at debugging/printf.c:7
7         return 0;

> Maybe I'm messing up the discussion by being confused about what the
> problem is that started the thread.  I thought what I heard is: the
> watchpoint traps with the PC pointing *after* the store, i.e., it
> points at the trap instruction, so it looks like two simultaneous
> stops.  
> 
> My point is that this is not correct reasoning: the watchpoint stop is
> at PC-instruction_size, which is in line 421 (last instruction of 421)
> and clearly different from line 422.  Yes, the hardware reports PC,
> not PC-instruction_size, but that's GDB's job to sort out, not the
> user's.

What I'm maintaining is that we shouldn't "sort this out".  What we
display should be, IMO, all the events which we consider to have
logically occurred in the current conditions.  The value of a
watchpoint has changed since we last checked it?  Report the
watchpoint.  We've reached the PC of a breakpoint?  Report the
breakpoint.

What you're suggesting would have two stops at identical PC values.
You'd want to say continue and have GDB stop again, right away, without
executing any instructions.  I'd find that much more confusing!

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> No, this is not the opposite of what I described; could you
 Daniel> explain why you think it is?  It's indistinguishable from
 Daniel> what I described.  If we set the PC to the PC of the
 Daniel> breakpoint, we assume we are past (have already hit) the
 Daniel> breakpoint.  Therefore when we're stopped by a watchpoint at
 Daniel> the PC of a breakpoint, it's sensible to treat this situation
 Daniel> to the user as if we have already hit the breakpoint.

You talked about a case where a user sets $pc.  That doesn't show up
in my discussion at all.  The program is just running, and hits a
watchpoint triggered by an action in source line 421.  It is really a
bad idea to pretend that we've stopped at a breakpoint on line 422.

The fact that some hardware may take the exception with PC pointing at
422 is not a valid reason to do otherwise.  It's conceivable that it's
unavoidable, if the hardware doesn't distinguish watchpoint from
breakpoint exceptions.  But, for example, on MIPS the two are
distinct.  So if I get a watch exception at PC 0x12340, I know that
the instruction that caused the watch is 0x1233c, which is line 421,
so that's what should be reported.  

The instruction that caused the exception is NOT the break, first of
all because it's at 0x12340 which is not the instruction address that
caused the exception, and second because the exception type (watch
exception) cannot be produced by a break instruction.

 Daniel> What I'm maintaining is that we shouldn't "sort this out".
 Daniel> What we display should be, IMO, all the events which we
 Daniel> consider to have logically occurred in the current
 Daniel> conditions.  The value of a watchpoint has changed since we
 Daniel> last checked it?  Report the watchpoint.  We've reached the
 Daniel> PC of a breakpoint?  Report the breakpoint.

 Daniel> What you're suggesting would have two stops at identical PC
 Daniel> values.  You'd want to say continue and have GDB stop again,
 Daniel> right away, without executing any instructions.  I'd find
 Daniel> that much more confusing!

Maybe you find it confusing because you're trying to reason about this
at the machine code level.  Look at the source line level instead.  

If you watch foo, you should be told about watchpoint stops at lines
that touch foo.  You should not be told about breaks in other lines.
If you hit at watchpoint in line 421, and you continue, and you had
defined a breakpoint in line 422, you would expect that breakpoint to
fire because 422 != 421.

For that matter, if you do this, then in fact you DID execute one
instruction, namely the break instruction.  Also, if you recognize
that watch exceptions are caused by the instruction at PC-size, and
break instructions are caused by the instruction at PC, it all makes
even more sense -- the triggering instruction is NOT the same, and if
you take BOTH the exception type AND the exception PC into account in
the analysis, you will get the correct answer.

As far as I remember from the break/watch analysis code, this is all
perfectly doable, even if it isn't the way it's currently coded.  

	  paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 04:37:50PM -0500, Paul Koning wrote:
>  Daniel> What I'm maintaining is that we shouldn't "sort this out".
>  Daniel> What we display should be, IMO, all the events which we
>  Daniel> consider to have logically occurred in the current
>  Daniel> conditions.  The value of a watchpoint has changed since we
>  Daniel> last checked it?  Report the watchpoint.  We've reached the
>  Daniel> PC of a breakpoint?  Report the breakpoint.
> 
>  Daniel> What you're suggesting would have two stops at identical PC
>  Daniel> values.  You'd want to say continue and have GDB stop again,
>  Daniel> right away, without executing any instructions.  I'd find
>  Daniel> that much more confusing!
> 
> Maybe you find it confusing because you're trying to reason about this
> at the machine code level.  Look at the source line level instead.  

It's precisely because I am reasoning about this at the source code
level that I find it confusing; we are stopped at the source location
of the breakpoint.  The fact that the breakpoint hasn't physically
triggered is, as far as I'm concerned, just an implementation detail.
Please take another look at my single-step example in the last message.

> If you watch foo, you should be told about watchpoint stops at lines
> that touch foo.  You should not be told about breaks in other lines.
> If you hit at watchpoint in line 421, and you continue, and you had
> defined a breakpoint in line 422, you would expect that breakpoint to
> fire because 422 != 421.

But you don't "hit a watchpoint in line 421".  When you hit the
watchpoint, you are already at line 422.  There's no way to "back up"
the view we prevent to the user (excluding simulators); for instance
the store may have been in the branch delay slot, so we could have come
from absolutely anywhere.  Other architectures may trigger the
watchpoint multiple cycles later when the pipeline has cleared up a
bit.  Your later comment that "watch exceptions are caused by the
instruction at PC-size" assumes far too much.

If there were a way to back up the view, and we did it, then of course
I'd agree we weren't stopped at the breakpoint.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 >>  Maybe you find it confusing because you're trying to reason about
 >> this at the machine code level.  Look at the source line level
 >> instead.

 Daniel> It's precisely because I am reasoning about this at the
 Daniel> source code level that I find it confusing; we are stopped at
 Daniel> the source location of the breakpoint.  The fact that the
 Daniel> breakpoint hasn't physically triggered is, as far as I'm
 Daniel> concerned, just an implementation detail.  Please take
 Daniel> another look at my single-step example in the last message.

 >> If you watch foo, you should be told about watchpoint stops at
 >> lines that touch foo.  You should not be told about breaks in
 >> other lines.  If you hit at watchpoint in line 421, and you
 >> continue, and you had defined a breakpoint in line 422, you would
 >> expect that breakpoint to fire because 422 != 421.

 Daniel> But you don't "hit a watchpoint in line 421".  When you hit
 Daniel> the watchpoint, you are already at line 422.  There's no way
 Daniel> to "back up" the view we prevent to the user (excluding
 Daniel> simulators); for instance the store may have been in the
 Daniel> branch delay slot, so we could have come from absolutely
 Daniel> anywhere.  Other architectures may trigger the watchpoint
 Daniel> multiple cycles later when the pipeline has cleared up a bit.
 Daniel> Your later comment that "watch exceptions are caused by the
 Daniel> instruction at PC-size" assumes far too much.

 Daniel> If there were a way to back up the view, and we did it, then
 Daniel> of course I'd agree we weren't stopped at the breakpoint.

I see the point.  If you have hardware that has imprecise watchpoint
exceptions, then indeed you're hosed.  You might be anywhere, and in
that case the watchpoint feature is going to be quite unuseable
because the user will be pointed at a source line that is potentially
not even in the same source file as the triggering instruction.

However, the fact that some architectures have imprecise watchpoints
is no reason to force imprecision on those that can do better.  In
other words, this should be an example of target-dependent machinery:
if the target has the ability to determine the "PC of the watchpoint
trigger instruction" then it should do so, and the break/watch display
reporting machinery should use that information to report the
watchpoint at the "correct" source line.

I thought such machinery already existed, but I may be mixed up with
other target hooks or target macros that deal with advancing or
backing up the PC at breakpoints and watchpoints.

	paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 04:56:45PM -0500, Paul Koning wrote:
> However, the fact that some architectures have imprecise watchpoints
> is no reason to force imprecision on those that can do better.  In
> other words, this should be an example of target-dependent machinery:
> if the target has the ability to determine the "PC of the watchpoint
> trigger instruction" then it should do so, and the break/watch display
> reporting machinery should use that information to report the
> watchpoint at the "correct" source line.

I am not familiar with any hardware watchpoint implementation (onboard
registers, JTAG, whatever) that can supply "PC of the watchpoint
trigger instruction" usefully.  But I'm not familiar with a whole heck
of a lot of those, so...

Page table based watchpoints obviously could do this.

On architectures with fixed size instructions and precise watchpoints
and no delay slots, maybe you can get away with a subtraction, but I'm
not at all sure about that.  Hum, it looks like MIPS WatchHi/WatchLo
can actually point to the instruction itself.

But now we're off into wishlist land, I'm afraid.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 16:56:45 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
> 
> However, the fact that some architectures have imprecise watchpoints
> is no reason to force imprecision on those that can do better.

What do you mean by ``do better''?  Should we back up PC to the
instruction that triggered the watchpoint?  If we do, then when we
continue, the watchpoint will trigger again and again, ad nauseam.

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 16:37:50 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
> 
> The fact that some hardware may take the exception with PC pointing at
> 422 is not a valid reason to do otherwise.  It's conceivable that it's
> unavoidable, if the hardware doesn't distinguish watchpoint from
> breakpoint exceptions.

No, it's not a hardware limitation, it's a ``limitation'' (I think
it's rather a feature) of _any_ reasonable implementation of
watchpoints, even software watchpoints: a watchpoint _always_ breaks
_after_ the instruction that writes to the watched location.  It
cannot be any other way, because no debugger and no hardware can
possibly know whether an instruction will write to an arbitrary
location before running that instruction.

Therefore, when a watchpoint triggers, we will _always_ be after the
instruction already executed.  The only hardware-specific aspect here
is whether the value of PC as reported by the target reflects that
fact, but that's a quirk of the hardware, not of the reality (I think
GDB fixes $pc to always behave as if the PC were after the instruction,
to reflect the reality).  In reality, the faulting instruction is
always behind us, and we already are at the next instruction.  In your
example, the next instruction is the one where the user put the
breakpoint, so we are _exactly_ at the place where it should break.

In other words, if line 421 writes to a watched location, then when
the watchpoint triggers, we are already after line 421, i.e. at line
422 (since, as I wrote earlier, there's no location between those two
lines where we could be).

> But, for example, on MIPS the two are
> distinct.  So if I get a watch exception at PC 0x12340, I know that
> the instruction that caused the watch is 0x1233c, which is line 421,
> so that's what should be reported.  

We know this on x86 as well, but this is a different issue.  Knowing
that the instruction at 0x1233c wrote to a watched address says nothing
about _where_ is the PC of the program at the time we are told that.

> The instruction that caused the exception is NOT the break, first of
> all because it's at 0x12340 which is not the instruction address that
> caused the exception, and second because the exception type (watch
> exception) cannot be produced by a break instruction.

You seem to suggest that we back up one instruction after a watchpoint
triggers.  Is that true?  If so, I think it's not a good idea, since
(1) we'd have the watchpoint trigger again when we continue after
that, and (2) the user who knows (as they all should, IMHO) that a
watchpoint always triggers _after_ the code that wrote to the data
will be utterly confused by that.

> Maybe you find it confusing because you're trying to reason about this
> at the machine code level.  Look at the source line level instead.  

I hope I explained above that on both levels we should see the same
conceptual picture: a watchpoint always triggers _after_ the code was
executed.  By contrast, a breakpoint always triggers _before_ the code
is executed.

> If you watch foo, you should be told about watchpoint stops at lines
> that touch foo.  You should not be told about breaks in other lines.

Again, this is mixing two subtly different aspects: one is where in
the code was the instruction that wrote to the watched location, the
other is where (i.e. at what PC) is the debuggee when we report the
watchpoint.

> If you hit at watchpoint in line 421, and you continue, and you had
> defined a breakpoint in line 422, you would expect that breakpoint to
> fire because 422 != 421.

And if you continue, what instruction will be the first one to be
executed, in your scheme?  It cannot be the first instruction of line
422, since the breakpoint should have triggered before that.  And it
cannot be the last instruction of line 421, because that would trigger
the same watchpoint again.  And there's no instruction in between
those two, so what can GDB do if we accept your views?  The only thing
it can do is not move at all, i.e. not resume the inferior, but
instead generate a breakpoint event out of thin air.  Is that what you
are saying we should do?

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Sat, Feb 18, 2006 at 01:10:13PM +0200, Eli Zaretskii wrote:
> I think at the core of this argument is this problem: there's no PC
> value that is _between_ two adjacent instructions.  Thus, being
> _after_ an instruction at a certain value of PC means that we at the
> same time are _at_ or _on_ the next instruction at PC+1.  And being
> _at_ an instruction where we put a breakpoint means that the
> breakpoint have already triggered, since breakpoints are expected to
> break _before_ the instruction executes.
> 
> Do you both agree with this interpretation?

This I agree with completely.

> If so, you should also
> both agree that being _after_ an instruction that wrote into a watched
> data location also means we are at the same precise location where a
> breakpoint was already supposed to break.  There's nothing in between
> these two locations, no place where we could stop _before_ getting to
> a place where a breakpoint should break.

And this.

On Sat, Feb 18, 2006 at 01:33:37PM +0200, Eli Zaretskii wrote:
> No, it's not a hardware limitation, it's a ``limitation'' (I think
> it's rather a feature) of _any_ reasonable implementation of
> watchpoints, even software watchpoints: a watchpoint _always_ breaks
> _after_ the instruction that writes to the watched location.  It
> cannot be any other way, because no debugger and no hardware can
> possibly know whether an instruction will write to an arbitrary
> location before running that instruction.

While I agree with your conclusions above, this bit's not right.

(A) Hardware can pretty straightforwardly trigger the exception while
executing the instruction, between address calculation and store
completion, and back up the PC.  I have been poring over the MIPS
documentation, but I haven't worked out yet whether this happens
or not.  However, I think some platforms do - I think this is what
HAVE_NONSTEPPABLE_WATCHPOINT is all about. 
HAVE_CONTINUABLE_WATCHPOINT, on the other hand, is going to usually
imply that we stop after the event.

(B) Most targets have few store instructions.  Not x86, true.  But
for others, disassembling the instruction at $pc to see where it will
read or write is pretty trivial.  ARM has maybe a dozen relevant
instructions at most.

(C) Page protection write watchpoints will always fault before the
store, and the OS will often provide the faulting address for you
in the signal information.

Do we want to uniformly present watchpoints as after-the-store, as
a least common denominator and for consistency?  If so, a reasonable
sort of thing to do, then all of the first part of this message
applies.  If not, it applies to targets on which watchpoints stop
after execution...

> You seem to suggest that we back up one instruction after a watchpoint
> triggers.  Is that true?  If so, I think it's not a good idea, since
> (1) we'd have the watchpoint trigger again when we continue after
> that, and (2) the user who knows (as they all should, IMHO) that a
> watchpoint always triggers _after_ the code that wrote to the data
> will be utterly confused by that.

... except for this, which is the same problem I described for
breakpoints; that's a compelling reason to behave as we do now.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Sat, 18 Feb 2006 10:46:53 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Paul Koning <pkoning@equallogic.com>, ghost@cs.msu.su,
> 	gdb@sources.redhat.com
> 
> Do we want to uniformly present watchpoints as after-the-store, as
> a least common denominator and for consistency?

Don't we do this already?  I thought we did.

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Sat, Feb 18, 2006 at 06:23:14PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 18 Feb 2006 10:46:53 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Paul Koning <pkoning@equallogic.com>, ghost@cs.msu.su,
> > 	gdb@sources.redhat.com
> > 
> > Do we want to uniformly present watchpoints as after-the-store, as
> > a least common denominator and for consistency?
> 
> Don't we do this already?  I thought we did.

Yes, sorry I was unclear - that is what we do (although I think the
implementation could use a little improvement, based on past
conversations on this list).  Just wanted to present that there are,
in fact, alternatives.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Sat, 18 Feb 2006 12:42:15 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Feb 18, 2006 at 06:23:14PM +0200, Eli Zaretskii wrote:
> > > Date: Sat, 18 Feb 2006 10:46:53 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Paul Koning <pkoning@equallogic.com>, ghost@cs.msu.su,
> > > 	gdb@sources.redhat.com
> > > 
> > > Do we want to uniformly present watchpoints as after-the-store, as
> > > a least common denominator and for consistency?
> > 
> > Don't we do this already?  I thought we did.
> 
> Yes, sorry I was unclear - that is what we do (although I think the
> implementation could use a little improvement, based on past
> conversations on this list).  Just wanted to present that there are,
> in fact, alternatives.

Well, FWIW, I think what we do is The Right Thing, and not just for
consistency's sake.

Re: MI: reporting of multiple breakpoints

[Paul Koning]

It's really frustrating that this is so hard to explain.

Yes, it is likely that the exception PC for a watchpoint exception
points after the store, not at it.

And it certainly is always true that you want to resume after the
store, not on it.

However, the issue isn't the value of PC at the exception.

The issue is: what user watch/break is reported, and what line is
reported?

My argument is: if the hardware permits you to know the PC of the
store, then you can do a BETTER job helping the user, by translating
the address of the store, NOT the exception PC, back into a line
number.  That way, you will tell the user that execution stopped at a
source line that does a store, rather than a source line that does
something entirely different.

If the hardware allows this, why do anything less?

   paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Sun, Feb 19, 2006 at 01:13:13PM -0500, Paul Koning wrote:
> It's really frustrating that this is so hard to explain.
> 
> Yes, it is likely that the exception PC for a watchpoint exception
> points after the store, not at it.
> 
> And it certainly is always true that you want to resume after the
> store, not on it.
> 
> However, the issue isn't the value of PC at the exception.
> 
> The issue is: what user watch/break is reported, and what line is
> reported?
> 
> My argument is: if the hardware permits you to know the PC of the
> store, then you can do a BETTER job helping the user, by translating
> the address of the store, NOT the exception PC, back into a line
> number.  That way, you will tell the user that execution stopped at a
> source line that does a store, rather than a source line that does
> something entirely different.
> 
> If the hardware allows this, why do anything less?

Because it's likely to mess up the rest of the user experience.

If you have the option to stop before the store has executed, then
there's a choice: fast-forward to after the store, or show the user
that the store is about to occur.  Right now, as Eli and I discussed
yesterday, we do the former.  There's two advantages in this: we're
consistent between platforms with different capabilities, and it's
clear that the watchpoint won't be re-hit when we continue.

You could make an argument to overrule the consistency point, and find
some clever technical solution to the re-hitting point, perhaps.

But you're talking about something different: retrieving or deducing
a different, related PC value and displaying source where the store
occured.

While this is useful, it needs to be done separately from the view we
present to the user of "where you are right now", which is what the
displayed source corresponds to.  Otherwise, the user will be presented
a view of the world in which the store hasn't happened yet, but
discover that, in fact, it has!

Now, could we separately show "watchpoint occured at foo.c:15" if the
hardware permits?  Yeah, sure.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Robert Dewar]

Daniel Jacobowitz wrote:

> Because it's likely to mess up the rest of the user experience.
> 
> If you have the option to stop before the store has executed, then
> there's a choice: fast-forward to after the store, or show the user
> that the store is about to occur.  Right now, as Eli and I discussed
> yesterday, we do the former.  There's two advantages in this: we're
> consistent between platforms with different capabilities, and it's
> clear that the watchpoint won't be re-hit when we continue.

Yes, obviously you want to point to the store that caused the
change if you have this information.

Yes, obviously when you continue, you want to continue from the
point at which the watchpoint was signalled.

> But you're talking about something different: retrieving or deducing
> a different, related PC value and displaying source where the store
> occured.

Right, that's what is needed
> 
> While this is useful, it needs to be done separately from the view we
> present to the user of "where you are right now", which is what the
> displayed source corresponds to.  Otherwise, the user will be presented
> a view of the world in which the store hasn't happened yet, but
> discover that, in fact, it has!

Absolutely, presenting the location of the store as where you
are now would be plain wrong I think.
> 
> Now, could we separately show "watchpoint occured at foo.c:15" if the
> hardware permits?  Yeah, sure.

Yes, that seems the most desirable solution (and the only
possible acceptable improvement to the current behavior).
Changing things to fudge the location to the store would
indeed be confusing.
> 

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Sun, 19 Feb 2006 13:13:13 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: drow@false.org, ghost@cs.msu.su, gdb@sources.redhat.com
> 
> Yes, it is likely that the exception PC for a watchpoint exception
> points after the store, not at it.

No, the PC for the inferior's current address points after the store.
The PC for whatever instruction caused the watchpoint exception points
at that instruction.  We are talking about 2 different values of PC.

> The issue is: what user watch/break is reported, and what line is
> reported?

We report the right watch and the right line.  What we fail to do is
run the commands of the breakpoint whose location is the instruction
right after the one which caused the watchpoint exception.  We need to
run those commands even if we decide not to announce the breakpoint.

> My argument is: if the hardware permits you to know the PC of the
> store, then you can do a BETTER job helping the user, by translating
> the address of the store, NOT the exception PC, back into a line
> number.

We already do this.  In fact, we did this from day one of watchpoint
support.  And we do this on all platforms that support watchpoints.

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 16:19:43 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
> 
> > Exactly my point.  The case you're talking about is the opposite of
> > the one I was talking about.
> > 
> > The program runs, executes the store into foo.  GDB should report
> > hitting the watchpoint on foo, and should NOT report hitting the
> > breakpoint at 422.
> > 
> > User says "step".  We execute one instruction, which is the breakpoint
> > trap, and report that as the breakpoint at line 422.  User is happy.
> 
> No, this is not the opposite of what I described; could you explain why
> you think it is?  It's indistinguishable from what I described.  If we
> set the PC to the PC of the breakpoint, we assume we are past (have
> already hit) the breakpoint.  Therefore when we're stopped by a
> watchpoint at the PC of a breakpoint, it's sensible to treat this
> situation to the user as if we have already hit the breakpoint.

I think at the core of this argument is this problem: there's no PC
value that is _between_ two adjacent instructions.  Thus, being
_after_ an instruction at a certain value of PC means that we at the
same time are _at_ or _on_ the next instruction at PC+1.  And being
_at_ an instruction where we put a breakpoint means that the
breakpoint have already triggered, since breakpoints are expected to
break _before_ the instruction executes.

Do you both agree with this interpretation?  If so, you should also
both agree that being _after_ an instruction that wrote into a watched
data location also means we are at the same precise location where a
breakpoint was already supposed to break.  There's nothing in between
these two locations, no place where we could stop _before_ getting to
a place where a breakpoint should break.

> What I'm maintaining is that we shouldn't "sort this out".  What we
> display should be, IMO, all the events which we consider to have
> logically occurred in the current conditions.  The value of a
> watchpoint has changed since we last checked it?  Report the
> watchpoint.  We've reached the PC of a breakpoint?  Report the
> breakpoint.

I agree.

> What you're suggesting would have two stops at identical PC values.

Right.

> You'd want to say continue and have GDB stop again, right away, without
> executing any instructions.  I'd find that much more confusing!

Agreed.

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 >> Date: Fri, 17 Feb 2006 16:19:43 -0500 From: Daniel Jacobowitz
 >> <drow@false.org> Cc: eliz@gnu.org, ghost@cs.msu.su,
 >> gdb@sources.redhat.com
 >> 
 >> > Exactly my point.  The case you're talking about is the opposite
 >> of > the one I was talking about.
 >> > 
 >> > The program runs, executes the store into foo.  GDB should
 >> report > hitting the watchpoint on foo, and should NOT report
 >> hitting the > breakpoint at 422.
 >> > 
 >> > User says "step".  We execute one instruction, which is the
 >> breakpoint > trap, and report that as the breakpoint at line 422.
 >> User is happy.
 >> 
 >> No, this is not the opposite of what I described; could you
 >> explain why you think it is?  It's indistinguishable from what I
 >> described.  If we set the PC to the PC of the breakpoint, we
 >> assume we are past (have already hit) the breakpoint.  Therefore
 >> when we're stopped by a watchpoint at the PC of a breakpoint, it's
 >> sensible to treat this situation to the user as if we have already
 >> hit the breakpoint.

 Eli> I think at the core of this argument is this problem: there's no
 Eli> PC value that is _between_ two adjacent instructions.  

No, that isn't my point.

My point is that, at least on some of the platforms, a watchpoint
exception will deliver the PC of the instruction doing the store, or
that PC can be deduced.  Therefore, on such platforms, that is the PC
that should be reported, which will make the report point to the right
source line.  Of course, the resume will not resume there, but GDB
already has machinery for that.

Daniel's comments are entirely valid for the case where you cannot
know the PC of the store -- certainly in that case you may end up with
a PC that happens to match that of a breakpoint, and in that case you
may end up reporting the watchpoint stop at the break line, and end up
not doing the break when you resume.  Fine, if that's the best your
hardware permits, but that isn't universally true.

	 paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Sun, Feb 19, 2006 at 01:08:41PM -0500, Paul Koning wrote:
> My point is that, at least on some of the platforms, a watchpoint
> exception will deliver the PC of the instruction doing the store, or
> that PC can be deduced.  Therefore, on such platforms, that is the PC
> that should be reported, which will make the report point to the right
> source line.  Of course, the resume will not resume there, but GDB
> already has machinery for that.

I've got no idea what you mean by "GDB already has machinery for that". 
Want to clarify?

We present a source location based on the current frame, which is a PC
derived from the current register values.  What you see is what you get
when you continue.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Sun, Feb 19, 2006 at 01:08:41PM -0500, Paul Koning wrote:
 >> My point is that, at least on some of the platforms, a watchpoint
 >> exception will deliver the PC of the instruction doing the store,
 >> or that PC can be deduced.  Therefore, on such platforms, that is
 >> the PC that should be reported, which will make the report point
 >> to the right source line.  Of course, the resume will not resume
 >> there, but GDB already has machinery for that.

 Daniel> I've got no idea what you mean by "GDB already has machinery
 Daniel> for that".  Want to clarify?

I'm referring to various target macros (don't remember the names) that
control whether the PC needs to be advanced before you continue from a
stop.  I remember using some of those when I implemented watchpoint
support on our MIPS platform.

 Daniel> We present a source location based on the current frame,
 Daniel> which is a PC derived from the current register values.  What
 Daniel> you see is what you get when you continue.

Ok, my point is that we can do better.  Your point (previous message)
is that you don't think what I'm suggesting is better.  I guess we'll
just disagree on that.  I prefer to tell users a store happened in a
source line that contains an assignment, rather than a source line
that doesn't.  The fact that some hardware can't do that doesn't alter
that -- we don't and shouldn't just offer lowest common denominator.

	    paul

Re: MI: reporting of multiple breakpoints

[Robert Dewar]

Paul Koning wrote:

> Ok, my point is that we can do better.  Your point (previous message)
> is that you don't think what I'm suggesting is better.  I guess we'll
> just disagree on that.  I prefer to tell users a store happened in a
> source line that contains an assignment, rather than a source line
> that doesn't.  The fact that some hardware can't do that doesn't alter
> that -- we don't and shouldn't just offer lowest common denominator.

You are NOT telling the user that, the current location is the
point at which you stopped. I think it would be actively confusing
to pretend you stopped at the store when you did not.

Fudging the current location seems wrong to me.

It *is* a good idea to tell the user where the store was
if you know, but that's completely different from the
information as to where you stopped.

In some hardware debuggers, you can stop several instructions
past the store, but you know where the store is. It would
be really confusing to a user to list variables and see that
assignments past the supposed current location have already
occurred in unoptimized code.

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Robert" == Robert Dewar <dewar@adacore.com> writes:

 Robert> Paul Koning wrote:
 >> Ok, my point is that we can do better.  Your point (previous
 >> message) is that you don't think what I'm suggesting is better.  I
 >> guess we'll just disagree on that.  I prefer to tell users a store
 >> happened in a source line that contains an assignment, rather than
 >> a source line that doesn't.  The fact that some hardware can't do
 >> that doesn't alter that -- we don't and shouldn't just offer
 >> lowest common denominator.

 Robert> You are NOT telling the user that, the current location is
 Robert> the point at which you stopped. I think it would be actively
 Robert> confusing to pretend you stopped at the store when you did
 Robert> not.

 Robert> Fudging the current location seems wrong to me.

 Robert> It *is* a good idea to tell the user where the store was if
 Robert> you know, but that's completely different from the
 Robert> information as to where you stopped.

 Robert> In some hardware debuggers, you can stop several instructions
 Robert> past the store, but you know where the store is. It would be
 Robert> really confusing to a user to list variables and see that
 Robert> assignments past the supposed current location have already
 Robert> occurred in unoptimized code.

That's true.  That isn't the case in the platform I know best -- there
it wouldn't be misleading to report the store point only, because
nothing else has happened yet.  But if you have a deep pipe that does
run to completion, then things would be different.  So yes, reporting
something like "stopped at foo.c:425 due to a store watchpoint at
foo.c:421" would be ideal.

	   paul

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Sun, Feb 19, 2006 at 01:38:17PM -0500, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
> 
>  Daniel> On Sun, Feb 19, 2006 at 01:08:41PM -0500, Paul Koning wrote:
>  >> My point is that, at least on some of the platforms, a watchpoint
>  >> exception will deliver the PC of the instruction doing the store,
>  >> or that PC can be deduced.  Therefore, on such platforms, that is
>  >> the PC that should be reported, which will make the report point
>  >> to the right source line.  Of course, the resume will not resume
>  >> there, but GDB already has machinery for that.
> 
>  Daniel> I've got no idea what you mean by "GDB already has machinery
>  Daniel> for that".  Want to clarify?
> 
> I'm referring to various target macros (don't remember the names) that
> control whether the PC needs to be advanced before you continue from a
> stop.  I remember using some of those when I implemented watchpoint
> support on our MIPS platform.

Those assume that the store has not been executed - if we had "backed
up" to the store, it would be re-executed.  I'm sure you can think of
an example where that wouldn't make the user happy.

On Sun, Feb 19, 2006 at 01:54:13PM -0500, Paul Koning wrote:
> run to completion, then things would be different.  So yes, reporting
> something like "stopped at foo.c:425 due to a store watchpoint at
> foo.c:421" would be ideal.

Since I just suggested something similar, I think we're making progress
here :-)

If you want to contribute support for this, since you obviously have
access to and interest in a platform which supports it, I'm sure we
could find a way to present the information to the user.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Sun, Feb 19, 2006 at 01:38:17PM -0500, Paul Koning wrote:
 >> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
 Daniel> I've got no idea what you mean by "GDB already has machinery
 Daniel> for that".  Want to clarify?
 >>  I'm referring to various target macros (don't remember the names)
 >> that control whether the PC needs to be advanced before you
 >> continue from a stop.  I remember using some of those when I
 >> implemented watchpoint support on our MIPS platform.

 Daniel> Those assume that the store has not been executed - if we had
 Daniel> "backed up" to the store, it would be re-executed.  I'm sure
 Daniel> you can think of an example where that wouldn't make the user
 Daniel> happy.

Yes, infinite loops tend to annoy people... :-)

 Daniel> On Sun, Feb 19, 2006 at 01:54:13PM -0500, Paul Koning wrote:
 >> run to completion, then things would be different.  So yes,
 >> reporting something like "stopped at foo.c:425 due to a store
 >> watchpoint at foo.c:421" would be ideal.

 Daniel> Since I just suggested something similar, I think we're
 Daniel> making progress here :-)

 Daniel> If you want to contribute support for this, since you
 Daniel> obviously have access to and interest in a platform which
 Daniel> supports it, I'm sure we could find a way to present the
 Daniel> information to the user.

Ok, I'll give that a look.  Thanks to all for the help.

    paul

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Sun, 19 Feb 2006 13:08:41 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: ghost@cs.msu.su, gdb@sources.redhat.com
> 
> My point is that, at least on some of the platforms, a watchpoint
> exception will deliver the PC of the instruction doing the store, or
> that PC can be deduced.

I think this happens on _all_ platforms that support watchpoints.

> Therefore, on such platforms, that is the PC that should be
> reported, which will make the report point to the right source line.

We already do precisely that.

Again, the place that caused the store is known (and shown to the
user), but the place where the inferior is stopped is a different
place on many architectures, including x86.  Wed are arguing about the
latter, not the former.

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Sun, Feb 19, 2006 at 09:52:14PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 19 Feb 2006 13:08:41 -0500
> > From: Paul Koning <pkoning@equallogic.com>
> > Cc: ghost@cs.msu.su, gdb@sources.redhat.com
> > 
> > My point is that, at least on some of the platforms, a watchpoint
> > exception will deliver the PC of the instruction doing the store, or
> > that PC can be deduced.
> 
> I think this happens on _all_ platforms that support watchpoints.

Really?  On x86, I suspect that the exception is always at the
instruction following the store; so it's possible, although
non-trivial, to identify the store by backtracking.  Is that right? 
But I can easily imagine this not being the case on some architecture
with delay slots.

> > Therefore, on such platforms, that is the PC that should be
> > reported, which will make the report point to the right source line.
> 
> We already do precisely that.
> 
> Again, the place that caused the store is known (and shown to the
> user), but the place where the inferior is stopped is a different
> place on many architectures, including x86.  Wed are arguing about the
> latter, not the former.

Could you give me an example?  I think that is desirable, but not at
all what we do today - I have no idea how to retrieve the address of
the store when I stop at a watchpoint.  We show the old and new value,
but that's it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Sun, 19 Feb 2006 16:54:33 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Paul Koning <pkoning@equallogic.com>, ghost@cs.msu.su,
> 	gdb@sources.redhat.com
> 
> > > exception will deliver the PC of the instruction doing the store, or
> > > that PC can be deduced.
> > 
> > I think this happens on _all_ platforms that support watchpoints.
> 
> Really?  On x86, I suspect that the exception is always at the
> instruction following the store; so it's possible, although
> non-trivial, to identify the store by backtracking.

The exception happens right when the store is written, and we find the
PC to be after the faulting instruction, when the inferior stops.  The
faulting instruction is the one that corresponds to the previous PC
value.

> > Again, the place that caused the store is known (and shown to the
> > user), but the place where the inferior is stopped is a different
> > place on many architectures, including x86.  Wed are arguing about the
> > latter, not the former.
> 
> Could you give me an example?

What should the example show?

> I think that is desirable, but not at all what we do today - I have
> no idea how to retrieve the address of the store when I stop at a
> watchpoint.  We show the old and new value, but that's it.

We also show the current source line, don't we?  Are you saying that
we show the wrong line?

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Mon, Feb 20, 2006 at 07:06:58AM +0200, Eli Zaretskii wrote:
> The exception happens right when the store is written, and we find the
> PC to be after the faulting instruction, when the inferior stops.  The
> faulting instruction is the one that corresponds to the previous PC
> value.

Yes.  On x86 it's possible to deduce the "previous PC value" but that's
not always the case.

> > > Again, the place that caused the store is known (and shown to the
> > > user), but the place where the inferior is stopped is a different
> > > place on many architectures, including x86.  Wed are arguing about the
> > > latter, not the former.
> > 
> > Could you give me an example?
> 
> What should the example show?

Us showing "the place that caused the store" to the user.  I don't
think we do this or have ever done this.

> > I think that is desirable, but not at all what we do today - I have
> > no idea how to retrieve the address of the store when I stop at a
> > watchpoint.  We show the old and new value, but that's it.
> 
> We also show the current source line, don't we?  Are you saying that
> we show the wrong line?

We show the old value, the new value, and the source line containing
$pc, but not the location of the store.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 15:01:50 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: ghost@cs.msu.su, gdb@sources.redhat.com
> 
> It is a bad thing for the break at x to fail due to the bad luck of
> having a watch exception at the preceding instruction.

I agree.  But the current code was written for a reason, I think, so
I'm curious to know what was that reason.

> If the two stops happened to be the SAME instruction, then you have
> plausible deniability.

Yes; except that if they happen on the same instruction, they are
still two different events: the breakpoint breaks _before_ the
instruction, the watchpoint _after_ it.  At least on x86.  So we can
announce both even in this case.

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 09:56:46PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:44:26 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > 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.
> 
> Why do we step around the breakpoint?  As long as we do that, the
> breakpoint never happened, and we don't need to announce it.  If we
> _want_ to announce it, we should stop stepping around it, IMHO.

All this long predates me, you understand.  I can only give you my
interpretation, not a real reason.  But the status quo seems reasonable
enough to me.

Consider a store which causes two user-placed watchpoints to trigger -
this is pretty easy since there is a non-trivial mapping between user
watchpoints and watched values.  We want to report both watchpoints.
But we were, physically, only stopped for one of them.

It's the same thing with breakpoints.  A breakpoint is "stop the
program when you reach address FOO".  We've reached address FOO; the
fact that something _else_ caused us to stop at the same time seems
only marginally relevant.

We step around it because we want to announce the breakpoint when
we first reach the relevant PC; if we're at FOO and say continue
then normally we won't hit the breakpoint at FOO, because after
hitting that breakpoint we present $pc == FOO to the user.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 15:05:58 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> Consider a store which causes two user-placed watchpoints to trigger -
> this is pretty easy since there is a non-trivial mapping between user
> watchpoints and watched values.  We want to report both watchpoints.
> But we were, physically, only stopped for one of them.

No, I think we were stopped by both of them.  They both watch the same
address, so they both fired when the location gets written.

And indeed we do announce both watchpoints today, right?

> It's the same thing with breakpoints.  A breakpoint is "stop the
> program when you reach address FOO".  We've reached address FOO; the
> fact that something _else_ caused us to stop at the same time seems
> only marginally relevant.
> 
> We step around it because we want to announce the breakpoint when
> we first reach the relevant PC; if we're at FOO and say continue
> then normally we won't hit the breakpoint at FOO, because after
> hitting that breakpoint we present $pc == FOO to the user.

But what about the commands associated with that breakpoint?  We've
reached the address and stopped, allright, but we didn't run the
commands the user wanted us to, did we?

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 10:19:12PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 15:05:58 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > Consider a store which causes two user-placed watchpoints to trigger -
> > this is pretty easy since there is a non-trivial mapping between user
> > watchpoints and watched values.  We want to report both watchpoints.
> > But we were, physically, only stopped for one of them.
> 
> No, I think we were stopped by both of them.  They both watch the same
> address, so they both fired when the location gets written.

If they were set using the same watchpoint register, they "both"
triggered trivially.  If they were set using different hardware
watchpoint resources, then the target almost certainly reported only
one of them.

> And indeed we do announce both watchpoints today, right?

Yes, that's why I was drawing the parallel.

> > It's the same thing with breakpoints.  A breakpoint is "stop the
> > program when you reach address FOO".  We've reached address FOO; the
> > fact that something _else_ caused us to stop at the same time seems
> > only marginally relevant.
> > 
> > We step around it because we want to announce the breakpoint when
> > we first reach the relevant PC; if we're at FOO and say continue
> > then normally we won't hit the breakpoint at FOO, because after
> > hitting that breakpoint we present $pc == FOO to the user.
> 
> But what about the commands associated with that breakpoint?  We've
> reached the address and stopped, allright, but we didn't run the
> commands the user wanted us to, did we?

We should run them when we stop.  That's what I'm trying to say :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 15:24:19 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> > No, I think we were stopped by both of them.  They both watch the same
> > address, so they both fired when the location gets written.
> 
> If they were set using the same watchpoint register, they "both"
> triggered trivially.  If they were set using different hardware
> watchpoint resources, then the target almost certainly reported only
> one of them.

But, as you well know, GDB will think that both were reported, due to
the way we currently find out which watchpoint triggered.

> > But what about the commands associated with that breakpoint?  We've
> > reached the address and stopped, allright, but we didn't run the
> > commands the user wanted us to, did we?
> 
> We should run them when we stop.  That's what I'm trying to say :-)

Do we run them now?  If not, I think we agree that we should fix that.

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 10:28:07PM +0200, Eli Zaretskii wrote:
> > > But what about the commands associated with that breakpoint?  We've
> > > reached the address and stopped, allright, but we didn't run the
> > > commands the user wanted us to, did we?
> > 
> > We should run them when we stop.  That's what I'm trying to say :-)
> 
> Do we run them now?  If not, I think we agree that we should fix that.

I think arranging to print everything we consider "hit" will fix this
as a side effect.  At least I hope so.

We've discussed this exact behavior before, by the way, and I think we
reached the exact same conclusion, but no one fixed it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 14:44:26 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> > 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? 

Well, then perhaps the question is why does bpstat_print exits the
loop when it sees PRINT_SRC_AND_LOC:

  for (; bs; bs = bs->next)
    {
      val = print_bp_stop_message (bs);
      if (val == PRINT_SRC_ONLY 
	  || val == PRINT_SRC_AND_LOC 
	  || val == PRINT_NOTHING)
	return val;
    }

Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 09:59:13PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:44:26 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > > 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? 
> 
> Well, then perhaps the question is why does bpstat_print exits the
> loop when it sees PRINT_SRC_AND_LOC:
> 
>   for (; bs; bs = bs->next)
>     {
>       val = print_bp_stop_message (bs);
>       if (val == PRINT_SRC_ONLY 
> 	  || val == PRINT_SRC_AND_LOC 
> 	  || val == PRINT_NOTHING)
> 	return val;
>     }

I've no idea.  I assume it's to show the first relevant breakpoint
message, and we might need to redesign the code and interface a bit if
we wanted more than one to be presented.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: reporting of multiple breakpoints

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 17 Feb 2006 18:01:13 +0300
> 
> It seems that for stop on multiple breakpoints, MI reports only one:
> 
>     (gdb)
>     -break-insert main
>     ^done,bkpt={number="1",type="breakpoint".....
>     (gdb)
>     -break-insert main
>     ^done,bkpt={number="2",type="breakpoint"......
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>    *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={...}
> 
> Is this a bug, or by design?

I think it's a bug.  I don't see any reason not to report all the
breakpoints.  As Daniel says, this is not limited to MI.  (You will
see in "info breakpoints" that GDB does know that both breakpoints
triggered, it just doesn't print them both.)