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

[Jim Blandy <jimb at redhat dot com>]

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.

> 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"?

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