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

[Jason Molenda]

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