One small caveat. > On Apr 3, 2015, at 4:04 PM, Jason Molenda <ja...@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. 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. _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
