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

[Hafiz Abid Qadeer]

On 20/01/15 20:15:15, Jason Molenda wrote:
> 
> > 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.

Jim & Jason,
Thanks for explaining this in details. I also like the ability provided 
by functions like QueueThreadPlanForStepOverRange. You can experiment 
by providing your own step plan if you want in your process plugin.

Regards,
Abid