Re: MI: reporting of multiple breakpoints

[Robert Dewar <dewar@adacore.com>]

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