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

[Zachary Turner]

It's not in process.  It's actually designed specifically for debuggers to
use for walking stacks of target processes.

On Thu Jan 15 2015 at 4:42:30 PM Jason Molenda <jmolenda at apple.com> wrote:

> You'd want to look at the UnwindLLDB and RegisterContextLLDB classes.
>
> UnwindLLDB is the top-level class which lldb asks "hey can you give me
> another stack frame above this one".  UnwindLLDB creates a RegisterContext
> for that stack frame -- a RegisterContextLLDB -- and so when someone wants
> to ask "what's the saved pc value for this stack frame", it goes to the
> register context and knows how to retrieve that.
>
> My biggest concern about the API you mention is whether it assumes that it
> is doing an in-process unwind.  lldb is an external process so if the API
> is looking at lldb's symbols and memory layout, that isn't going to do you
> any good.
>
> But it may be possible to delegate all of this to another API assuming it
> can work on another process.  So when you ask for the value of rbx in frame
> 2, the RegisterContext for that frame would bounce over to the windows api,
> get the result and hand it back to lldb.
>
> J
>
> > On Jan 15, 2015, at 4:38 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > Thanks, I wasn't aware of the distinction.
> >
> > As an aside, Windows comes with an API that does its own unwinding.  It
> works quite well and is aware of many minor details such as Microsoft
> specific compiler flags that affect the way code is generated, and also
> works (somewhat) in the presence of FPO, no symbols, and other edge cases.
> If I wanted to make unwinding on Windows use this API, what would be the
> best way to fit that in to LLDB?  In theory it would replace UnwindLLDB for
> any situation where the binary was using a Microsoft ABI.
> >
> > On Thu Jan 15 2015 at 4:36:39 PM <jingham at apple.com> wrote:
> >
> > > On Jan 15, 2015, at 4:18 PM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > > Which is unfortunate, because it seems to be needed even for basic
> stepping to work, like step over.  Originally I was just trying to
> implement stepping, and that's how I ran into this issue.  So that brings
> me to a related question.  Why is step over as complicated as it is?  It
> seems to me like step over can be implemented by disassembling 1 opcode,
> adding the size of the opcode to the current pc, and having the
> ThreadPlan::ShouldStop always return false unless the pc is equal to old_pc
> + size_of_opcode.
> > >
> >
> > You are describing "thread step-inst".  That should pretty much always
> work regardless of unwinder, etc.
> >
> > Source step over, as Jason said, is much more complicated.
> >
> > Jim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150116/89147358/attachment.html>