This is the mail archive of the 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]

Re: remote protocol extension for step out of range


> Unfortunately, GDB still insists on inserting and removing breakpoints
> around each step, so things aren't quite as efficient as they could be.
> I think in time even that can be fixed.

Leaving breakpoints in all the time would probably greatly improve
performance. This is exactly what we do when debugging ChorusOS using
the Microtec XRAY debugger, at both applicative (Ethernet) and system
(serial line) level. XRAY leaves the breakpoints in all the time, but
requires that the debug server hides them when memory is being read.
The debug servers currently forbid overwriting them, but could also
transparently re-insert a breakpoint after an underlying code
modification has been performed, assuming the instruction boundaries
did not change. Of course, hardware breakpoints are removed or disabled
systematically at each stop, but this is done by the server itself.

    Breakpoints are actually even automatically re-inserted by the
    debug server (applicative debug only) at program restart time,
    unless the binaries in which they are located have changed, but
    this is probably more questionable. The advantage is that the
    debugger needs to issue only one request to restart a program.
    This fits with the paradigm of issuing only one remote request to
    start execution or to get the full state after a stop.

I think this optimization could be dealt-with in the target vector
itself, and we will probably attempt to implement it at some point in
the ChorusOS target vector code which we are developping currently.
Breakpoint removes could be ignored except if GDB does not re-insert
them when performing the target_resume() operation, assuming we already
hide the breakpoints.

BTW, since this thread was originally about optimizing stepping,
ChorusOS debug servers have a special step mode called "step till next
function call or return". Combined with "nexti", it is handy in order
to quickly understand what a given piece of unknown code does at
execution time or where it fails, by executing it from function call to
function call and looking at return values. I guess such a command
could be added to GDB as well (if it does not exist already, I am still
relatively new to all this :-).

-Adam Mirowski

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