Re: MI: reporting of multiple breakpoints

Paul Koning
2006-02-19T18:54:23Z

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