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

[Reid Kleckner]

On Fri, Jan 16, 2015 at 12:44 PM, <jingham at apple.com> wrote:
>
> 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.
>

Nice.

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.
>

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.

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.

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.
>

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