[lldb-dev] Enabling single-step mode and acting on each executed instruction

[Vangelis Tsiatsianas via lldb-dev]

Thank you very much for your replies! 

I took a look at ThreadPlanTracer and found out that the crash reason was the call of a virtual method during object construction:

virtual Process.UpdateThreadList()
└── ProcessGDBRemote.UpdateThreadList()
    └── new ThreadGDBRemote()
        └── new Thread()
            └── new ThreadPlanBase()
                ├── new ThreadPlanAssemblyTracer()
                └── virtual ThreadPlanAssemblyTracer::EnableTracing()
                    └── virtual ThreadPlanTracer::TracingStarted()
                        └── virtual Thread::GetRegisterContext() ← Virtual method call of Thread under construction!
                            └── __cxa_pure_virtual()

I believe I fixed the bug and also tried to make the tracing API a little better.

In order to correct the logic, I had to add a call to Thread::GetTraceEnabledState() (somewhat expensive) in Thread::ShouldStop(), which looks like a hot path and thus I was a bit hesitant about it. Ideally, changing a setting (here: target.process.thread.trace-thread) should trigger a callback, however I couldn’t find any such mechanism ―does it exist?

You may find the relevant patch attached. It was generated against llvm-8.0.0 git tag (commit SHA: d2298e74235598f15594fe2c99bbac870a507c59).


― Vangelis


P.S.: How can I submit this patch for review?




> On 28 Jun 2019, at 20:50, Jim Ingham <jingham at apple.com> wrote:
> 
> Stop hooks only trigger when control is about to be returned to the user.  And in its normal mode, lldb doesn't step instruction all the time anyway...  So I don't think they would do what Vangelis wants.  He would have to drive the debugger with only the step-instruction command, which I think qualifies as interfering with stepping.
> 
> The ThreadPlanTracer is really the ticket, it does force the debugging to only instruction single step when it is realizing the more complex stepping operations, and then has hooks on each instruction stop.
> 
> Sean and I added this facility way way back in the early days of lldb because we needed it to figure out some problems with the expression parser.  We weren't really sure whether we were going to promote it more broadly and were waiting for some more interest to spend time cleaning it up and writing tests, etc.  Then years passed... So it is not entirely surprising that the facility needs some attention.  If somebody wants to take a stab at making this work reliably again, that would be awesome!
> 
> Jim
> 
> 
> 
>> On Jun 28, 2019, at 7:09 AM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 
>> You want to set up a stop-hook.
>> 
>> See “help target stop-hook”, specifically “help target stop-hook add”.
>> 
>> target stop-hook add -o “register read pc”
>> will read the pc each time the target stops.
>> 
>> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Vangelis Tsiatsianas via lldb-dev
>> Sent: Friday, June 28, 2019 6:16 AM
>> To: via lldb-dev <lldb-dev at lists.llvm.org>
>> Cc: Vangelis Tsiatsianas <vangelists at icloud.com>
>> Subject: [EXT] [lldb-dev] Enabling single-step mode and acting on each executed instruction
>> 
>> Hello,
>> 
>> I would like to set the target in single-step mode and perform an action right after each instruction is executed. Notably, it is crucial to do so transparently, i.e. without interfering with user breakpoints, watchpoints, stepping etc..
>> 
>> Could you provide me with some guidance on how to accomplish it? 🙂
>> 
>> I have found the target.process.thread.trace-thread option and the relevant classes (ThreadPlanTracer and ThreadPlanAssemblyTracer), which although seem to not work and also crash the debugger when enabled.
>> 
>> Thank you very much, in advance.
>> 
>> 
>> ― Vangelis
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190630/aece1890/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ThreadTracingFix.patch
Type: application/octet-stream
Size: 7828 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190630/aece1890/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190630/aece1890/attachment-0001.html>