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

["Eli Zaretskii" <eliz@elta.co.il>]

> Date: Wed, 15 Oct 2003 18:41:34 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > 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

I'm with Michael here.  You might recall that I originally suggested
to call those impl_breakpoint's just ``locations'' or ``addresses''
of a particular breakpoint.

If ``location'' is not good enough (after all, there's other
information stored about each address, like the kind of trap we set
there), let's use some more vague word, like bp_spot or maybe
bp_instance.

>  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.

That's just a choice of words that confuses you.  I suggest a
different choice of words: the target sets a breakpoint according
information in bp_location; a struct breakpoint can cause a target to
set the breakpoint in several locations (or at several addresses).