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

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Oct 16, 2003 at 10:25:26AM -0400, Andrew Cagney wrote:
> >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.
> 
> BTW, long term, this stuff is going to be hijacked by other *point 
> mechanisms.  Variable watchpoints, for instance, will be given a similar 
> projection (the watchpoint changes that last year stalled can probably 
> be picked up again).  While the term "breakpoint" may continue to be 
> used, it will be applied to more than just breakpoints.

Shorter term than you may think :)  My plan now is something like this:
  - Cleanup patches, as posted
  - Internal support for multiple locations per breakpoint
  - Adapt watchpoints to use the multiple locations support, which will
    be rather cleaner than what we have now.
  - Then move on to fun stuff with breakpoints.

Could you give me a pointer to the watchpoint changes you're talking
about?  I don't recall them.

> PS: To make everyone feel ill - logical_debugpoint, physical_debugpoint ...

That's the concept, but I don't think we have a real problem with
continuing to overload breakpoint for that.  Consider "info break".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer