Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning@equallogic.com>]

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