Any way to avoid inserting & removing breakpoints?

Any way to avoid inserting & removing breakpoints?

[J.T. Conklin]

I finished my breakpoint extensions prototype, and discovered that GDB
inserts all enabled breakpoints when program execution is resumed, and
removes them when it regains control.  

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.

	--jtc

Re: Any way to avoid inserting & removing breakpoints?

[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

Re: Any way to avoid inserting & removing breakpoints?

[Stan Shebs]

jtc@RedBackNetworks.com (J.T. Conklin) writes:

> I finished my breakpoint extensions prototype, and discovered that GDB
> inserts all enabled breakpoints when program execution is resumed, and
> removes them when it regains control.  

Yes, this is a "feature".  It's pretty well wired into GDB.  It might
be possible to make insert_breakpoints() and remove_breakpoints() do
some sort of caching-like thing, but I'm not sure that all target
memory reads know about substituting original code, so you might get
punished when you're doing disassembly or prologue analysis.

							Stan

Re: Any way to avoid inserting & removing breakpoints?

[Todd Whitesel]

> some sort of caching-like thing, but I'm not sure that all target
> memory reads know about substituting original code, so you might get
> punished when you're doing disassembly or prologue analysis.

They don't. See breakpoint.c:read_memory_nobpt() and grep for callers.

As of 4.17 there were references in mips-tdep.c, but I don't think anywhere
else. I am only concerned with 32-bit cross targets though.

Todd Whitesel
toddpw @ wrs.com

Re: Any way to avoid inserting & removing breakpoints?

[J.T. Conklin]

> jtc@RedBackNetworks.com (J.T. Conklin) writes:
> > I finished my breakpoint extensions prototype, and discovered that GDB
> > inserts all enabled breakpoints when program execution is resumed, and
> > removes them when it regains control.  
> 
> Yes, this is a "feature".  It's pretty well wired into GDB.  It might
> be possible to make insert_breakpoints() and remove_breakpoints() do
> some sort of caching-like thing, but I'm not sure that all target
> memory reads know about substituting original code, so you might get
> punished when you're doing disassembly or prologue analysis.

You're right, target memory reads don't know about substituting the
original code.  I got around that problem by having my stub restore
memory before control is returned to GDB and to (re-)insert break-
points just before program execution resumes.

I haven't investigated, but it's conceivable that some ROM monitors do
the same thing (for much the same reasons --- simplifying internal
disassembly).  If GDB was extended to avoid inserting and removing
breakpoints, it could only be used on targets that manage breakpoints
in this manner.

	--jtc

-- 
J.T. Conklin
RedBack Networks