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

[Yao Qi <yao at codesourcery dot com>]

On 10/04/2013 08:53 PM, ILG.Robert wrote:
> 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.

The mail body is a good place to describe these packets.  IWBN to give
the rsp traffic with and without the patch, and highlight the
difference.  gdb/doc/gdb.texinfo should be updated to include these two
new packets, but you can do it later.

> > > >>...
> > >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.

I am not familiar with your target, so I don't understand why
"debugging with GDB runs into a dead end".  Sounds like breakpoint is 
supported on your stub, but why does "finish" not work properly?

> 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.

IMO, it is not a problem specific to your target.  It needs a fix in GDB 
rather than proposing a new rsp packet.

> 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.

Looks your motivation is for functional purpose, range stepping is not
suitable to you.  Your generalization doesn't look reasonable to me.
We can have a look at supported actions of vCont, 'c,C,s,S,t,r'.  They
are quite low-level and primitive.  However, in your proposal, vCont;n 
and vCont;f are about "step to a new line" and "step out of this 
function", why are quite high-level to me.

On the other hand, these two packets can't be exercised in other 
people's environment, because we don't have your stub and gdbserver 
doesn't support them.  I am afraid that these piece of code will be 
rotten in the tree as GDB evolves.

--
Yao (éå)