Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Paul Koning <pkoning@equallogic.com>
Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
Subject: Re: MI: reporting of multiple breakpoints
Date: Sun, 19 Feb 2006 18:31:00 -0000	[thread overview]
Message-ID: <20060219181912.GA19352@nevyn.them.org> (raw)
In-Reply-To: <17400.46393.531000.150247@gargle.gargle.HOWL>

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


  reply	other threads:[~2006-02-19 18:19 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17 15:32 Vladimir Prus
2006-02-17 15:48 ` Daniel Jacobowitz
2006-02-17 16:04   ` Vladimir Prus
2006-02-17 18:59     ` Daniel Jacobowitz
2006-02-17 19:04       ` Daniel Jacobowitz
2006-02-17 19:52     ` Eli Zaretskii
2006-02-17 19:54       ` Daniel Jacobowitz
2006-02-17 19:59         ` Eli Zaretskii
2006-02-17 20:06           ` Paul Koning
2006-02-17 20:08             ` Daniel Jacobowitz
2006-02-17 20:16               ` Eli Zaretskii
2006-02-17 20:19                 ` Daniel Jacobowitz
2006-02-17 20:18               ` Paul Koning
2006-02-17 20:24                 ` Daniel Jacobowitz
2006-02-17 21:37                   ` Paul Koning
2006-02-17 21:43                     ` Daniel Jacobowitz
2006-02-17 21:56                       ` Paul Koning
2006-02-17 22:12                         ` Daniel Jacobowitz
2006-02-18  9:54                           ` Paul Koning
2006-02-18 10:56                             ` Daniel Jacobowitz
2006-02-18 15:47                             ` Eli Zaretskii
2006-02-18 15:28                         ` Eli Zaretskii
2006-02-18 17:28                           ` Daniel Jacobowitz
2006-02-18 17:42                             ` Eli Zaretskii
2006-02-18 17:50                               ` Daniel Jacobowitz
2006-02-18 18:33                                 ` Eli Zaretskii
2006-02-19 18:20                           ` Paul Koning
2006-02-19 18:31                             ` Daniel Jacobowitz [this message]
2006-02-19 18:44                               ` Robert Dewar
2006-02-20  3:16                             ` Eli Zaretskii
2006-02-18 11:39                       ` Eli Zaretskii
2006-02-19 18:19                         ` Paul Koning
2006-02-19 18:38                           ` Daniel Jacobowitz
2006-02-19 18:54                             ` Paul Koning
2006-02-19 19:05                               ` Robert Dewar
2006-02-19 19:30                                 ` Paul Koning
2006-02-19 19:52                                   ` Daniel Jacobowitz
2006-02-19 19:57                                     ` Paul Koning
2006-02-19 21:55                           ` Eli Zaretskii
2006-02-20  4:33                             ` Daniel Jacobowitz
2006-02-20  7:25                               ` Eli Zaretskii
2006-02-20 18:20                                 ` Daniel Jacobowitz
2006-02-17 20:14             ` Eli Zaretskii
2006-02-17 20:08           ` Daniel Jacobowitz
2006-02-17 20:22             ` Eli Zaretskii
2006-02-17 20:31               ` Daniel Jacobowitz
2006-02-17 20:32                 ` Eli Zaretskii
2006-02-17 20:41                   ` Daniel Jacobowitz
2006-02-17 20:02         ` Eli Zaretskii
2006-02-17 20:15           ` Daniel Jacobowitz
2006-02-17 19:36 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060219181912.GA19352@nevyn.them.org \
    --to=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    --cc=pkoning@equallogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox