[lldb-dev] Problem unwinding from inside of a CRT function
rnk at google.com
Fri Jan 16 16:17:49 PST 2015
Cool, that seems reasonable.
Sent from phone
On Jan 16, 2015 4:04 PM, <jingham at apple.com> wrote:
> > On Jan 16, 2015, at 3:55 PM, Reid Kleckner <rnk at google.com> wrote:
> > On Fri, Jan 16, 2015 at 2:53 PM, Jason Molenda <jmolenda at apple.com>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev