[lldb-dev] Problem unwinding from inside of a CRT function
zturner at google.com
Thu Jan 15 16:47:20 PST 2015
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.
> > 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>
> > >
> > > 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...
More information about the lldb-dev