[lldb-dev] Problem unwinding from inside of a CRT function

[Jason Molenda]

> On Jan 20, 2015, at 4:21 AM, Hafiz Abid Qadeer <hafiz_abid at mentor.com> wrote:
> 
> 
> 
> GDB also has range stepping thing now.
> https://sourceware.org/ml/gdb-patches/2013-03/msg00450.html



Jim points out that this is a different approach than lldb took -- it's pushing some limited amount of single instruction stepping down into the remote stub.

The cost of single instruction stepping can be broken down into (1) time to stop the inferior process, (2) time to communicate inferior state between stub and debugger, and (3) time for the debugger decide whether to resume the process or not.

The gdb approach reduces 2 & 3.  lldb's approach is addressing all of 1-3.  A single source line may have many function calls embedded within it -- printf("%d\n", f(g(x))); -- so lldb will still be need to stop the inferior 4 more times than gdb for this sequence (stop at the point of the call instruction, then single instruction step into the call -- whereas with gdb's approach the stub will single instruction step into the call and then report back to gdb).  

In lldb we've put a lot of time in optimizing #2.  Besides getting rid of the "acks" in the gdb-remote protocol by default (needed for an unreliable transport medium, like a raw serial connection to a target board), we looked at what pieces of information lldb needs to decide whether to keep stepping or stop.  It needs to know the stop reason, it needs to know the pc, it needs the stack pointer, and it probably needs the frame pointer.  So in the "T" packet which the stub sends to indicate that the inferior has stopped, we have a list of "expedited registers" - register values that the stub provides without being asked.

The result is that every time lldb needs to step a single instruction within a function bounds, there are two packets sent:  The "T05" packet indicating the inferior stopped, and lldb sending back another "vCont;s" packet saying to instruction step again, if appropriate.  The overhead of #2 has been dramatically reduced by this approach.   (think about a scenario where there are no expedited registers in the T packet - the debugger is going to need to ask for each of these registers individually, or get all registers via the g packet, and it's going to be really slow.)


The approach Jim did with lldb does assume that you have a disassembler with annotations regarding whether an instruction can affect flow control - branches, calls, jumps, etc.  The llvm disassembler includes these annotations.  Last time I looked at the disassembler gdb is using, it doesn't include this kind of information about instructions.

J