Should be possible to create an Unwind and RegisterContext subclasses to work with this. There are several different subclasses that you can look at - UnwindLLDB/RegisterContextLLDB are fairly sophisticated/complicated. A more trivial example to start with would be UnwindMacOSXFrameBackchain and RegisterContextMacOSXFrameBackchain.
> On Jan 15, 2015, at 4:47 PM, Zachary Turner <ztur...@google.com> wrote: > > 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 <jmole...@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 <ztur...@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 <jing...@apple.com> wrote: > > > > > On Jan 15, 2015, at 4:18 PM, Zachary Turner <ztur...@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 > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
