Re: Any way to avoid inserting & removing breakpoints?

[toddpw@wrs.com (Todd Whitesel)]

> Although I'm not surprised by this behavior, it would be preferable if
> the target itself was responsible for managing, inserting and removing
> breakpoints.  Then a lot of the traffic on the debugging channel could
> be avoided.  I didn't see anything in the GDB source that suggests
> this is possible; but I'm hoping I'm missing something.

At Wind River we use GDB with targets that manage their own breakpoints.

When I took over maintenance of the local GDB last August, I inherited a
fair amount of not-so-clean code sprinked throughout breakpoint.c and our
backend, and I don't like the way infrun.c interacts with it. For some
reason, wait_for_inferior occasionally wants to pull out all the breakpoints
and do something specific, and let them get pushed back in later. This
seems to me to never be a good idea.

I've already written one "breakpoint management layer" at a previous job.
It seems to me that factoring out such a thing would be the correct model
for GDB also. However I would prefer to put a single target_manage_breakpoint
item in the target vector so that all breakpoint functions are switched at
once, rather than exposing lots of little primitives and bloating the target
vector struct. Is there an established GDB rule about this sort of thing?

At work I now have authorization to rework+submit our local GDB patches,
but some accumulated project fires must be put out first and our office
is moving during the holidays so I am taking a vacation during that time.

So if you don't need this improvement for at least a month or two, then
you should just be able to pick up what I submit (assuming I can get it
past Stan that is :) ).

Todd Whitesel
toddpw @ wrs.com