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

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

[ILG.Robert]

[-- 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¬

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

[Yao Qi]

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 (齐尧)

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

[Pedro Alves]

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

Or really, those assembly functions have wrong or missing unwind info.

-- 
Pedro Alves

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

[ILG.Robert]

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

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

I haven’t been able to trace back the exact problem. If the target denies to insert a breakpoint for "finish", GDB will crash later while debugging because it suddenly uses rotten addresses. If GDB is not informed about the problem of setting such a breakpoints, you can continue debugging without any problem. It looks like as GDB contains an incomplete error handling.

>>> 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.
>
> Pedro Alves: Or really, those assembly functions have wrong or missing unwind info.

Indeed that's exactly the problem. 

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

Indeed "Next" can be replaced by "range-stepping". It seems that this might work for us. 

All the same "finish" is needed in order to handle the GDB "finish" correctly. Remember that our target cannot insert breakpoints to system code, like other targets cannot alter read-only memory. So if you trigger the system to call a call-back function of your code, you cannot step back. The Stack would look like this: MyCode1-->SystemCode2-->...-->Systemcode4-->MyCode5. As you cannot insert a breakpoint to SystemCode4 there is no way to "finish" until MyCode1. In such a case GDB or the target need to realize that the code in between cannot be controlled with breakpoints and therefore the breakpoint needs to be set to the return address of MyCode1 - skipping all code in between. GDB does not skip unknown code at the moment, so the question is whether skipping unknown Code has to be done by GDB or by the target (remote by using "finish").

By the way these RSP commands are not as high level as you think they are. "Next" does not skip a whole line. It only skips a possible function call. Such no DWARF2 information is needed - only the stack and the a few assembler instructions need to be evaluated.

So the real questions are:
Is it intended to skip unknown/read-only code in GDB?
If yes, has it to be solved within GDB or within the target?


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

Thanks,
Robert Ilg