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

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > This is a series of eight patches which begin to clean up our infrastructure
 > for tracking breakpoints.  More specifically, I chose to split the struct
 > breakpoint into two: one which is logically associated with the user's
 > "break" command, and one which is logically associated with an insertable
 > breakpoint.  The general idea is that the mapping should be one-to-many
 > eventually.  Right now it isn't and there's a long way to go before we can
 > get there, but this is a first step.
 > 

This is certainly the right direction. We have discussed this in very
general terms (I believe at the gcc conference), but I don't remember
a discussion on the gdb lists. Since this seems quite a big rewrite (I
am not sure, I just saw all this stuff appearing at once), how about
using the branching approach? It has worked well for a few features now.

elena


 > This will make it simpler to have, for instance, a breakpoint on both the
 > in-charge and not-in-charge constructors without bothering the user with
 > that detail.  Similarly (eventually!) for copies of an inlined function, or
 > multiple copies of an executed line.  This is a bit of a ways in the future
 > but I'm working on it.
 > 
 > On the infrastructure side we will be able to have an "impl_breakpoint"
 > (short for implementation; better naming ideas?) for each location we are
 > watching using hardware watchpoints.  This will simplify a lot of code.  It
 > will also eventually become easier to object-orient our breakpoints.
 > 
 > Except for a couple of minor bug fixes where noted, these patches change
 > nothing.  They use the assumption that every breakpoint has exactly one
 > implementation breakpoint.  After they've been applied, it's easy to find
 > conceptual layering issues; most (not all) references to b->impl are
 > potential problems, and some references to bpt->owner are also.  I've
 > converted functions which operated primarily on the impl to accept impl
 > breakpoint arguments instead of user breakpoint arguments.  Many of the
 > remaining layering issus deal with printing the address of a breakpoint; I'd
 > love to hear what other people think we should do for breakpoints with
 > multiple addresses.  Just say multiple, and provide a maint (or info)
 > command to look at them?
 > 
 > The actual patches will follow in separate messages.  Thoughts?  Comments on
 > the overall approach?  OK?
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer