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 retrieve 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
