[lldb-dev] Problem unwinding from inside of a CRT function

[Reid Kleckner]

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>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150116/e0b98d5a/attachment.html>