This is the mail archive of the gdb-patches@sourceware.org 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]
Other format: [Raw text]

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


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

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