This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: reporting of multiple breakpoints


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]