Thanks, I wasn't aware of the distinction. As an aside, Windows comes with an API <http://msdn.microsoft.com/en-us/library/windows/desktop/ms680650%28v=vs.85%29.aspx> 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
