[Lldb-commits] [lldb] r332922 - Work around some odd instruction single-step behavior on macOS.

[Pavel Labath via lldb-commits]

> > On May 22, 2018, at 9:37 AM, Jim Ingham <jingham at 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 <jingham at 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.