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

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Oct 08, 2003 at 01:05:34PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> 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 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.
> 
> This sounds really great.
> 
> When you think about what actually is happening in the debuggee, the
> mapping is actually many-to-many, since you can have multiple user
> breakpoints at the same address.  Not that this affects your data
> structures --- just an observation.

Right.  At the moment we use the duplicate flag to handle this; it may
be necessary to do it differently in the future, but it's hard to say.
I want to get a little further before I think about that.

> > 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.
> 
> How about "user breakpoints" and "machine breakpoints"?

I like it.

> > 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?
> 
> I think 'info break' should list the addresses.  I don't know how this
> should fit into the MI format, but it ought to be MI that changes,
> rather than omitting useful behavior.
> 
> In my ideal world, you'd get an explanation for why each address was
> chosen, when it's not obvious:
> 
> (gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
>                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
> (gdb) 

Here's the problem that I see.

For foo::foo, there are two of these things.  Having them both in the
list would be nice.  Really nice.

For inline_accessor_fn there are 3.8 million.  In addition to needing
to do a whole lot of work on GDB internals before we could survive this
(memory usage; ptrace thrashing inserting and removing them; linked
lists of breakpoints; and that's just the beginning) this has some
severe user interface implications.  We don't want to print out all
those addresses by default!

I'm open to suggestions on how to deal with this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer