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
