> > On May 22, 2018, at 9:37 AM, Jim Ingham <jing...@apple.com> wrote: > > > > I haven't played around with this yet. Can it also provide enough memory to pretend a stack trace? Most of the thread plan stuff will fall over pretty early if it doesn't have at least a couple of frames?
You can do anything, but there isn't much infrastructure for it yet, so simulating complex states is not going to be pretty. The reason I suggested this is because this deals with only instruction-level steps and not the fancy step-ins/outs, which require more stack frames, so /I hope/ a very rudimentary mock will be enough. I was thinking of something like: memory: 0x1000-0x2000: code, full of "nop" instructions 0x2000-0x3000: data full of zeroes registers: pc- points to 0x1000, then slowly advances sp - points to 0x2xxx other registers zero On Tue, 22 May 2018 at 17:38, Jim Ingham <jing...@apple.com> wrote: > BTW, I think it is likely that we are being interrupted, but the bug happens very infrequently and generally goes away when I turn on more than a trivial amount of logging, so it's been hard to prove that yet. Ah, interesting.. By "we" I assume you mean the process-under-debug (and not say debugserver of lldb). I am not sure how ptrace works on macos, but if it's anything like linux the interrupt signal will only get delivered after the process is resumed (and not while the debugger has it suspended). If that's the case then it should be possible to reproduce this fairly reliably by sending the signal (with kill) while the process is stopped at the breakpoint, and then attempting to step over it. _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
