RE: Extending RSP with vCont;n and vCont;f

["ILG.Robert" <R.ILG@bachmann.info>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2829 bytes --]

> Due to lack of description of these two packets, I have to understand them from the help message of the command.

According to your comments, you got it completely right. Please let me know if there is another place where I have to describe these two packages in detail.

>> ...
> IIUC, it is similar to range-stepping, vCont;r except that start and 
> stop address are not provided to the stub.  That means vCont;n requires a smarter stub to know enough line table information to decide where to stop.
>
> An alternative to me is to teach your stub understand range stepping.
>> ...
> GDB inserts a momentary breakpoint, resume the inferior and wait when 
> command "finish" is executed.  I don't think GDB emits a large number 
> of RSP packets in this process.  Do you have an experiment that vCont;f packet improves performance to some extent?

Indeed your comments are good points if only performance increase is considered. Yet we have other issues that require these packages to be used.

First of all we are debugging on a target that has no memory management per task/thread. To be more specific the controller manages memory access block wise. So whenever GDB sets a breakpoint to a memory address within a protected block (that is not part of the application being debugged), an exception on the controller would result. We avoid this by ignoring breakpoints to these well-known, protected blocks within our gdb-stub. If our target does not act differently on "next" and "finish", debugging with GDB runs into a dead end. Also consider that some target have read-only memory, where this will cause problems as well.

Second our system contains some assembler functions which do not build a stack frame as usually done by compiled c-code. When debugging these assembler functions GDB reacts as usual: it detects the call of external code and does a "continue" to the return address of the current stack frame. Yet this return address is not the caller - it is the caller of the caller and therefore a "step-into" does not only skip undebugable code, it also steps out of the currently debugged function. 

All in all our system has some limitations that are special for low-level targets. Our proposal is a  generalization on how GDB is currently working. Currently GDB does not expect the target to be able to do a step-over or a step-into. Yet a specific target should be able to override this behaviour by telling GDB that it is capable to do so. Such the target can do target-specific staff whatever is concerned (read-only memory, memory protection, timing, mutex - whatever comes into your mind). Step-range does not cover these scenarios and introducing specific code for different remote targets to GDB source seems to be wrong  to me.

Thanks,
Robert
\x16º&Öéj×!zÊÞ¶êç×N´ÛÙb²Ö«r\x18\x1dn–­r\x17¬