Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz <drow at mvista dot 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