Re: remote protocol extension for step out of range

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Adam" == Adam Mirowski <mir@solfege.France.Sun.COM> writes:
>> 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.

Adam> Leaving breakpoints in all the time would probably greatly improve
Adam> performance. This is exactly what we do when debugging ChorusOS using
Adam> the Microtec XRAY debugger, at both applicative (Ethernet) and system
Adam> (serial line) level. XRAY leaves the breakpoints in all the time, but
Adam> requires that the debug server hides them when memory is being read.

On many (most?) GDB targets, GDB inserts breakpoints with memory
writes instead of a higher level "insert breakpoint" command.  While
at this point (ie, I have not studied this in enough detail) I think
it might be easier to support keeping breakpoints installed only in
those targets that support high level breakpoint insertion/removal,
that would require that we maintain the current code that inserts and
removes breakpoints via memory reads/writes for all the other targets.
I think the aggregate complexity of such a scheme is greater than just
doing it for all targets.

For example, since GDB has to read the original contents of the memory
region (so it can replace it when the breakpoint is removed).  We just
need a mechanism so that those bits of memory overlay the actual
memory contents when doing a memory read.

Adam> The debug servers currently forbid overwriting them, but could also
Adam> transparently re-insert a breakpoint after an underlying code
Adam> modification has been performed, assuming the instruction boundaries
Adam> did not change. Of course, hardware breakpoints are removed or disabled
Adam> systematically at each stop, but this is done by the server itself.

When I added support for insert/remove breakpoint packets to the
remote protocol, I used a similar scheme in our debug agent.
Breakpoints instructions are written to memory when the agent resumes
target execution, and they are removed when the agent regains control.
I don't have any interlocks between memory writes and breakpoint adds,
but since GDB always removes breakpoints it hasn't been an issue.

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

I suppose you could probably do this all in the target vector.  That
seems somewhat hackish to me.  It just seems easier to go about this
in the higher layers.

I guess find out in as I investigate further.

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

So does the debug agent step instruction by instruction until a call
or ret instruction is reached?  Or does it disassemble starting from
the current PC?  Disassembly might be difficult to do concisely on 
some architectures, especially those with variable instruction size.

Of course, with step over range, the debugger can find when the next
call or ret instruction is located and limit the range to that insn.

        --jtc

-- 
J.T. Conklin
RedBack Networks