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

[jingham at apple.com]

BTW, Zachary's question here was not a dumb one.  A full stack backtrace is not cheap, so when hacking on lldb, never ask for more frames than you need.  It isn't as expensive as it was in gdb since we separate unwinding the pc/cfa from unwinding the arguments up the stack, but still, a full stack trace should only get done in response to some high level user request.  

Jim


> On Jan 20, 2015, at 1:16 PM, Jason Molenda <jason at molenda.com> wrote:
> 
> 
>> On Jan 20, 2015, at 1:06 PM, jingham at apple.com wrote:
>> 
>> 
>>> On Jan 20, 2015, at 12:31 PM, Zachary Turner <zturner at google.com> wrote:
>>> 
>>> In practice how slow is this for stepping over very lengthy calls?  It sounds like LLDB still generates a call stack at every branch point, which while certainly faster than generating one at every instruction, still seems like it has the potential to be very slow.  
>> 
>> At most, lldb only needs to get the current frame & its parent frame to run its stepping algorithm.  It won't generate a full stack frame unless you ask it to.  Getting two frames should be pretty quick.
> 
> Specifically -- it will take three packets.  The initial stop packet gives us enough registers to know what the current stack frame is.  lldb will make one memory read of the stack memory, which gives it enough to reconstruct the caller stack frame.  T packet, memory read, memory read result.  Then lldb knows whether to continue stepping, set a breakpoint & resume, or stop stepping.