<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 16, 2015 at 12:44 PM,  <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>Nice.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>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.</div></div></div></div>