[lldb-dev] Unwinding with no symbols

jingham at apple.com jingham at apple.com
Fri Apr 3 17:02:23 PDT 2015



> On Apr 3, 2015, at 4:08 PM, Jason Molenda <jason at molenda.com> wrote:
> 
> One small caveat.
> 
>> On Apr 3, 2015, at 4:04 PM, Jason Molenda <jason at molenda.com> wrote:
>> 
>> I think in our previous discussions you argued that lldb should *know* that it just single instruction stepped into a new function.  If that knowledge could be transmitted down to the unwinder, we could use the ABI::CreateFunctionEntryUnwindPlan unwind plan instead of the ABI::CreateDefaultUnwindPlan.  The former describes how to unwind when we're sitting at the first instruction of a function.  lldb doesn't have any ability to do this today, though.
> 
> This isn't as easy as I make it out to be.  The ThreadPlan knows that it instruction stepped and (1) left the range of addresses we're stepping through, and (2) the StackID has changed (the stack pointer has changed).
> 
> This is getting quickly more into Jim's bailiwick than mine but you can see two possibilities right away - we stepped out of our original function or we stepped into a new function.  If we assume an always-decreasing (on x86) stack pointer, we can disambiguate but there are people who do crazy things with discontiguous stacks that may not make that a safe assumption.

You really need to know in from the ABI who is responsible for changing the CFA.  If you know the callee always does this on the way in & then out again, then if the PC moved out of the range of the current function but the CFA hasn't changed yet you're probably stepping IN and thus on the first instruction (unless you are stepping out of a frameless function...)  And of course PC moved out of the range of the current function is also not reliable if you are stepping recursively.  Again, you can generally get this right in the easy cases.  But there are always exceptions...

> 
> I don't know how much knowledge the ThreadPlan has here, setting aside the issue of how to pass that knowledge down to the unwinder.

The ThreadPlans can capture whatever they need before each step.  Right now they store the pc & StackID they were stepping from.  But I'm not convinced that with just that and no help from the unwinder we can know with enough confidence what just happened to give useful hints.

Jim


> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev





More information about the lldb-dev mailing list