Yeah, good point. In that case, you could just update RegisterContextLLDB::SavedLocationForRegister(). Add a little code near the top that looks to see if there is the thread has an UnwindHint saying we've just stepped-in, and this is frame 0, then we use the CreateFunctionEntryUnwindPlan() unwind plan instead of whatever plan we would normally use here.
> On Jan 16, 2015, at 6:27 PM, jing...@apple.com wrote: > > So the steps I was thinking of were: > > 1) ThreadPlan notices it is on a branch > 2) ThreadPlan calls Thread::SetUnwindHint() which calls into the ABI to > write down whatever hints it thinks are appropriate and stuff them into the > thread. > 3) ThreadPlan causes the process to step one instruction > 4) Whoever goes to create the RegisterContexts & Frames for that thread will > have access to the Thread, and thus to the UnwindHint. So the ThreadPlan > doesn't have to get involved. > > I think that should work. > > Jim > > >> On Jan 16, 2015, at 5:43 PM, Jason Molenda <jmole...@apple.com> wrote: >> >> 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 re! trieve 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
