This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: reporting of multiple breakpoints
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.