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

[Ted Woodward]

"The initial stop packet gives us enough registers to know what the current
stack frame is."

Which registers would you suggest I have my simulator return in the stop
packet?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

-----Original Message-----
From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On
Behalf Of Jason Molenda
Sent: Tuesday, January 20, 2015 3:16 PM
To: Jim Ingham
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] Problem unwinding from inside of a CRT function


> 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.
_______________________________________________
lldb-dev mailing list
lldb-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev