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