<div dir="ltr">Jim,<br><br>>> Not sure if my current version of 'SimpleStep' is correct (I've made a few<br>>> changes since testing via 'thread step-scripted'), but nothing happens (no<br>>> prints on '__init__') when I add the class via 'StepUsingScriptedThreadPlan' in<br>>> the callback.<br>>><br>>> What's the proper way to do this?<br>>><br>><br>> What happens?  Did you look at the "step" log to see what lldb thought it was<br>> doing - i.e. "log enable -f /tmp/lldb-step-log.txt lldb step".  Also, what is<br>> lldb doing then nothing happens?<br><br>Apologies, by "nothing" I meant that the class code doesn't seem to be invoked.<br>Here's the output:<br><br>(lldb) log enable -f /tmp/lldb-step-log.txt lldb step<br>(lldb) breakpoint delete<br>About to delete all breakpoints, do you want to do that?: [Y/n] y<br>All breakpoints removed. (1 breakpoint)<br>(lldb) command script import scripted_step.py<br>Process 37849 stopped<br>* thread #1, stop reason = signal SIGSTOP<br>    frame #0: 0x000000010255e000 dyld`_dyld_start<br>dyld`_dyld_start:<br>->  0x10255e000 <+0>: pop    rdi<br>    0x10255e001 <+1>: push   0x0<br>    0x10255e003 <+3>: mov    rbp, rsp<br>    0x10255e006 <+6>: and    rsp, -0x10<br>(lldb) trace<br>trace done<br>Hello, world!<br>Process 37849 exited with status = 0 (0x00000000)<br><br>Note that the "trace" messages are printed, but nothing from the class in<br>between.<br><br>I'm also attaching the lldb step log for this run.  The SimpleStep class is<br>referenced in the log, but it's hard for me to understand what's going on since<br>I'm not familiar with the internals of lldb.  Do you see the problem?<br><br>Have you tried reproducing this?  debugserver just runs a "Hello, world!" program:<br><br>debugserver localhost:8000 main<br><br>> One thing I've recently found (in some other work I've been doing) is that if<br>> you run the step asynchronously, then the call that ran the thread plan still<br>> holds the API lock, and any calls the scripted thread plan makes block against<br>> the other plan holding the lock.<br>><br>> We already have a workaround for getting the "run lock" in Python code run for<br>> internal purposes.  That is a bit of a hack, using the notion that the internal<br>> state thread is always running code on behalf of the agent that had the API<br>> lock - even though it is running on a separate thread.  So we make a separate<br>> run lock for the internal state thread, and use that for code running on that<br>> thread.  We probably need to do the same thing for the Target API lock.<br><br>If it turns out to be relevant, will you be able to share this patch?  If you<br>don't want to add it to the tree, can you at least share it on the list?<br><br>Thanks,<br>Nikita<div><br></div></div>