The details will be a little tricky on this one. Frame 0 is probably created as soon as the process stops - before the ThreadPlan does anything -- and we need to install the UnwindHint in that frame 0 RegisterContextLLDB before we start asking anything about frame 1.
StackFrameList is where we call the Unwinder to get stack frames -- e.g. see StackFrameList::GetFrameAtIndex(). If the ThreadPlan had a chance to execute code before we try to retrieve stack frame 1 (which it seems like it would -- this is a private stop event and the ThreadPlan is the guy who is going to ask about stack frame 1 itself), we'd need some way to say give me the RegisterContext for frame 0 and stuff the UnwindHints in that object. e.g. see how RegisterContextLLDB::InitializeZerothFrame() sets its m_full_unwind_plan_sp. This is the UnwindPlan that will be used to find frame 1's pc, stack pointer, frame pointer, etc, when requested. J > On Jan 16, 2015, at 4:55 PM, jing...@apple.com wrote: > > One thing to be careful about if you do this is that there's no guarantee > that the ThreadPlan will be the first person to ask for the unwind, so there > might be a bad unwind sitting around. It would actually be a shame if > anybody else got their hands on a bad unwind when we knew how to make a > better one. So maybe the UnwindHint should hang off the Thread instead, so > anybody who goes to unwind will see it. > > Jim > > >> On Jan 16, 2015, at 4:17 PM, Reid Kleckner <r...@google.com> wrote: >> >> Cool, that seems reasonable. >> >> Sent from phone >> >> On Jan 16, 2015 4:04 PM, <jing...@apple.com> wrote: >> >>> On Jan 16, 2015, at 3:55 PM, Reid Kleckner <r...@google.com> wrote: >>> >>> On Fri, Jan 16, 2015 at 2:53 PM, Jason Molenda <jmole...@apple.com> wrote: >>> In my opinion, expending a lot of energy on making the ThreadPlans know how >>> to unwind from the first instruction is ignoring the real problem of being >>> able to unwind accurately from all instruction locations. It's not worth >>> doing. Make the unwinder work from any location on your platform - if it >>> can't, that's the problem that needs to be fixed. I agree I think it would >>> be interesting if the ThreadPlans could identify to the Unwinder that it >>> has just stepped in to a function for even better reliability in a >>> particularly tricky unwind scenario. But it's not a panacea, if that's the >>> only thing you fix and rely on "walk the frame chain on the stack" to >>> backtrace, you're going to have a horrible debugger experience. Even if >>> you can accurately walk the stack you won't get register save locations, >>> for instance, so when the debug info says a variable is stored in rbx in >>> the middle of the stack, and rbx was saved by the callee function to the >>> stack, you won't be able to retr! ieve it for the user. >>> >>> I don't think it's practical to expect the unwinder to *always* work, but I >>> agree it needs to work most of the time. There are situations when unwind >>> data just isn't available, like when trying to step over a call to a >>> function JITed by something you don't control. >>> >>> Personally, I think it will be a lot more work to make the unwinder >>> understand PDB information than it will to let ThreadPlan know what looks a >>> call instruction looks like. Clang will also be generating DWARF for the >>> forseeable future, so adding PDB reading only helps us debug third party >>> code, which not very interesting. Adding the call-recognition code to >>> ThreadPlan will solve the cross-platform problem of stepping over a call to >>> a function with no CFI. Would you be OK with patches in that direction? >>> >>> We do eventually want to use PDBs to support unwinding, but we expected to >>> get by with just DWARF for some time to come. >> >> >> We crossed paths... See the "UnwindHint" notion I sent in another mail on >> this thread. I like that approach better than having the ThreadPlans know >> about calls because it not only gets stepping right, but passing the hint to >> the unwinder would not only get the step in to stop as it should, but would >> also set the unwinder on the right path so that the backtrace at this point >> would also be correct... That's important for the user when we do step-in >> rather than step-over. >> >> Jim >> >> > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
