Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8]
Date: Wed, 15 Oct 2003 22:41:00 -0000	[thread overview]
Message-ID: <20031015224134.GA4102@nevyn.them.org> (raw)
In-Reply-To: <3F8C605E.1060604@redhat.com>

On Tue, Oct 14, 2003 at 01:45:18PM -0700, Michael Snyder wrote:
> I don't think any of those pairs would convey at first glance
> what the distinction is, to an average user (I hesitated to
> say "naive").  With your or my knowledge of debugger internals,
> we might look at almost any of those and figure out what they
> mean, but ask someone who doesn't know what a register is...
> 
> If this is just an internals issue, then toss a coin, it
> doesn't matter.  But for the picture that we present to the
> user, remember -- we always present a fictional picture that
> hides most of the underlying details.  The unsophisticated
> user thinks he is debugging his code -- not the underlying
> machine.  If possible, he doesn't want to know eg. that
> line seventeen has been broken into several locations and
> intermixed with code from 3 other lines.  We're sometimes
> forced to tell him anyway, but we don't if we can avoid it.
> 
> From that perspective, I think a breakpoint is a breakpoint.
> To the user it represents a location in the *source* code.
> The fact that this may translate to several locations in
> the machine code is "under the hood", so to speak.  If he
> wants that level of information, we should give it to him,
> but maybe the metaphor should reflect the fact that this is
> "what's inside the box", as opposed to, like, two different
> kinds of breakpoint (virtual/actual or whatever).  So for
> instance, we might say that *this* is the breakpoint, and
> if you want to know, *these* are the breakpoint's *locations*.
> 
> There -- you asked for my opinion.  Are you happy?   ;-)

Quite happy :)  This suggests struct breakpoint and struct bp_location
(or maybe even bp_element, which is clearer for watchpoints, but less
clear overall).  For this approach, I see:

 Pro: it's much clearer.
 Con: it gives breakpoint two meanings in the internals documentation;
      the target sets a breakpoint according to a bp_location; a struct
      breakpoint can cause the target to set many breakpoints.  But I
      think that if we have to be confused somewhere, that's the place
      to put the confusion.

Do others like this?  I have a couple of other flagged messages to
respond to in this thread, but they all seem to have moved onto the
general multi-breakpoints problem.

Michael, once we're agreed on a name could you review the cleanup
patches?  Then I'll put together a branch for the interesting bits.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  parent reply	other threads:[~2003-10-15 22:41 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 16:55 Daniel Jacobowitz
2003-10-08 17:33 ` Elena Zannoni
2003-10-08 19:04   ` Andrew Cagney
2003-10-08 19:07     ` Daniel Jacobowitz
2003-10-08 19:44       ` David Carlton
2003-10-08 20:36         ` Elena Zannoni
2003-10-08 19:49       ` Andrew Cagney
2003-10-08 18:07 ` Jim Blandy
2003-10-08 18:23   ` Joel Brobecker
2003-10-08 19:05   ` Daniel Jacobowitz
2003-10-08 19:52     ` Andrew Cagney
2003-10-08 20:30       ` Daniel Jacobowitz
2003-10-08 21:09         ` Andrew Cagney
2003-10-08 21:11           ` Daniel Jacobowitz
2003-10-08 21:40             ` Elena Zannoni
2003-10-08 22:28             ` Andrew Cagney
2003-10-09 19:19       ` Michael Snyder
2003-10-14  1:38         ` Daniel Jacobowitz
2003-10-14 15:40           ` Andrew Cagney
2003-10-14 15:46             ` David Carlton
2003-10-14 15:51             ` Daniel Jacobowitz
2003-10-14 16:27               ` Elena Zannoni
2003-10-14 20:45               ` Michael Snyder
2003-10-15 15:02                 ` Andrew Cagney
2003-10-15 18:20                   ` Michael Snyder
2003-10-15 18:30                     ` Andrew Cagney
2003-10-15 22:19                       ` Michael Snyder
2003-10-15 22:23                         ` Andrew Cagney
2003-10-15 22:37                           ` Michael Snyder
2003-10-15 18:56                     ` Elena Zannoni
2003-10-16  6:59                       ` Eli Zaretskii
2003-10-16 13:11                         ` Daniel Jacobowitz
2003-10-16 14:08                           ` Paul Koning
2003-10-16 14:21                           ` Elena Zannoni
2003-10-16 15:54                             ` Eli Zaretskii
2003-10-16 23:20                               ` Michael Snyder
2003-10-16 23:18                             ` Michael Snyder
2003-10-16 15:45                           ` Eli Zaretskii
2003-10-16 23:14                           ` Michael Snyder
2003-10-15 22:41                 ` Daniel Jacobowitz [this message]
2003-10-16  6:55                   ` Eli Zaretskii
2003-10-16 14:25                     ` Andrew Cagney
2003-10-16 16:02                       ` Eli Zaretskii
2003-10-16 23:24                         ` Michael Snyder
2003-10-17  6:46                           ` Eli Zaretskii
2003-10-17 21:38                             ` Michael Snyder
2003-10-18  8:43                               ` Eli Zaretskii
2003-10-20 18:48                                 ` Michael Snyder
2003-10-16 16:16                       ` Daniel Jacobowitz
2003-10-16 18:20                         ` Andrew Cagney
2003-10-16 23:26                           ` Totally OT Michael Snyder
2003-10-16 16:03                   ` RFA: Breakpoint infrastructure cleanups [0/8] David Carlton
2003-10-16 16:17                     ` Daniel Jacobowitz
2003-10-08 20:55     ` Elena Zannoni
2003-10-08 20:59       ` Daniel Jacobowitz
2003-10-09  6:09     ` Eli Zaretskii
2003-10-09 14:08       ` Daniel Jacobowitz
2003-10-09 17:02         ` Eli Zaretskii
2003-10-09 19:41           ` Daniel Jacobowitz
2003-10-19 16:43           ` Andrew Cagney
2003-10-09 19:33         ` Michael Snyder
2003-10-08 19:38   ` David Carlton
2003-10-08 21:00     ` Daniel Jacobowitz
2003-10-09  6:07     ` Eli Zaretskii
2003-10-08 18:26 ` Eli Zaretskii
2003-10-08 19:09   ` Daniel Jacobowitz
2003-10-19 15:55 ` Andrew Cagney
2003-10-19 16:39   ` Eli Zaretskii
2003-10-30  5:49     ` Daniel Jacobowitz
2003-11-03 18:00       ` Daniel Jacobowitz
2003-11-04 19:57       ` Michael Snyder
     [not found] <1065728983.12011.ezmlm@sources.redhat.com>
2003-10-09 20:01 ` Jim Ingham
2003-10-15 19:48 Michael Elizabeth Chastain
2003-10-15 22:00 ` Michael Snyder
2003-10-15 22:14 Michael Elizabeth Chastain
2003-10-15 22:36 ` Michael Snyder
     [not found] <1066321046.18949.ezmlm@sources.redhat.com>
2003-10-16 18:58 ` Jim Ingham
2003-10-16 23:30   ` Michael Snyder
2003-10-16 19:02 ` Jim Ingham
2003-10-17  7:04   ` Eli Zaretskii
2003-10-17 16:55     ` Jim Ingham

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=20031015224134.GA4102@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.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