<div dir="ltr">I think the first thing for us to try on the Windows side is to provide a simple implementation of an ABI plugin.  Earlier Jason mentioned that if you're at the start of a function LLDB will try to create a default unwinder by going through the ABI plugin, and that isn't happening for us on Windows, presumably because something somewhere is (correctly) objecting to the use of a SystemV ABI plugin on Windows.  So my first step will be to figure that out, make sure UnwindLLDB can create a default unwinder through my MicrosoftABI plugin, and then see how far that gets us.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 3:10 PM,  <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jan 16, 2015, at 1:42 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
><br>
> On Fri, Jan 16, 2015 at 12:44 PM, <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
> 1) In the original implementation, (and this is how gdb does it, BTW) lldb single-stepped till "something interesting happened."  As an optimization, when you are doing any kind of step through source range, I changed lldb so it runs from "instruction that could branch" to "instruction that could branch" using breakpoints.  Then when it hits an instruction that could branch it single steps that instruction, and then figures out from where that went what to do next.<br>
><br>
> Nice.<br>
><br>
> BTW, if it were helpful to figure out what to do next, we could store some info (the old stack frame or whatever) when we hit a branch instruction, and then use it when the single-step completed.  I haven't needed to do that yet, however; Jason's always been able to get the unwinder work reliably enough not to require this.<br>
><br>
> First, we should definitely teach the Windows unwinder to fall back to frame pointers if no debug info is present. That's an obvious win.<br>
<br>
</span>Yes.<br>
<span class=""><br>
><br>
> However, there are lots of environments (not just Windows) where unwinding is unreliable due to third party libraries, so it'd be nice if we can get by without unwinding.<br>
><br>
> 2) If the single step pushes a frame, and we are "stepping over", lldb sets a breakpoint on the return address and continues.  When the return address is hit (for the current frame of course since it could be hit recursively) then we continue stepping as above.<br>
><br>
> Any objection to asking the target if the previous opcode is something typically used for a call (x86 call, ARM bl), single step, and then load the retaddr or link register? Is that hard to thread through? I suppose it would fire on 32-bit x86 PIC sequences (call 0 ; pop %ebx), but that won't hurt.<br>
<br>
</span>The agents that manage stepping, etc (ThreadPlans) are persistent through-out the operation they manage.  They live in a little stack of operations, so there's always one entity per step type operation (i.e. if you next, hit a breakpoint, call a function, hit a breakpoint in the function, next again, etc. each of these operations has a Thread Plan to govern it.)  It wouldn't be hard to store some data in them, and use it either to convey hints to the unwinder when you step in, as Jason suggests, or whatever you needed to do.<br>
<br>
One thing, the ThreadPlans are currently architecture agnostic, and I'd like to keep it that way, so whatever you need to express should be done in an architecture-independent way.  That might add a little complexity, but one I think will be worthwhile long term.<br>
<br>
But I agree with Jason that, from a resource allocation standpoint, time spent on the unwinder would benefit the whole system much more than time spent hacking around its deficiencies in the ThreadPlans.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jim<br>
<br>
<br>
</font></span></blockquote></div><br></div>