This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFA: Breakpoint infrastructure cleanups [0/8]


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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]