<p dir="ltr">Cool, that seems reasonable.</p>
<p dir="ltr">Sent from phone</p>
<div class="gmail_quote">On Jan 16, 2015 4:04 PM,  <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jan 16, 2015, at 3:55 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
><br>
> On Fri, Jan 16, 2015 at 2:53 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> We do eventually want to use PDBs to support unwinding, but we expected to get by with just DWARF for some time to come.<br>
<br>
<br>
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.<br>
<br>
Jim<br>
<br>
<br>
</blockquote></div>