Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Oct 08, 2003 at 01:16:03PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > +/* GDB maintains two groups of breakpoints and related events.  One
> > +   group are the "implementation breakpoints"; these are minimal
> > +   structures used to manage stopping the program.  They map to a specific
> > +   stop reason (trap at a particular PC, for instance).  The other group
> > +   are "user breakpoints"; these carry higher-level information including
> > +   source locations and breakpoint conditions.  */
> 
> "minimal structures used to manage stopping the program" could be
> almost anything.  How about:
> 
>     GDB maintains two groups of breakpoints and related events.  One
>     group are the "implementation breakpoints" (struct
>     impl_breakpoint); these represent specific machine-level
>     mechanisms used to stop the program: trap instructions patched
>     into the code ("software breakpoints"), hardware breakpoints,
>     hardware watchpoint registers, and so on.
> 
>     The other group are "user breakpoints" (struct breakpoint); these
>     are the breakpoints as seen and manipulated by the user.  They
>     carry higher-level information like source locations and
>     breakpoint conditions.
> 
>     A single user breakpoint may use several implementation
>     breakpoints to get the right effect.  For example, the GNU C++
>     compiler emits two copies of each constructor: the 'in-charge'
>     constructor and the 'not-in-charge' constructor.  So a user
>     breakpoint on the constructor would have two separate
>     implementation breakpoints, one for each copy.

Thanks, I like it.  I'll adapt it into the next version.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer