<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I will to do so, starting with <a href="http://bugs.llvm.org" class="">bugs.llvm.org</a>. Thank you! π<div class=""><br class=""></div><div class=""><br class=""></div><div class="">β Vangelis<br class=""><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 2 Jul 2019, at 23:09, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Jul 2, 2019, at 11:52 AM, Vangelis Tsiatsianas <<a href="mailto:vangelists@icloud.com" class="">vangelists@icloud.com</a>> wrote:<br class=""><br class="">I would like to leave it as a suggestion for the future, just in case the need for such a mechanism arises in other places within LLDB or for plugins.<br class=""></blockquote><br class="">File an enhancement request with <a href="http://bugs.llvm.org" class="">bugs.llvm.org</a>, otherwise it will get lost. There's also a Projects page at <a href="http://lldb.llvm.org" class="">lldb.llvm.org</a> with a list of interesting ideas for additions to lldb - another place to mention this sort of enhancement - hough we should probably get more general agreement that this is a good direction before putting it there.<br class=""><br class="">Jim<br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class="">Thank you, once again, for your time and very helpful responses! <br class=""><br class=""><br class="">β Vangelis<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 2 Jul 2019, at 02:16, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:<br class=""><br class="">There isn't a general mechanism for external clients to watch settings changes. But IMO, it would be appropriate for the setter for the target.process.thread.trace-thread set function to go do this work. Having an explicit relationship between setting the setting and changing state in the threads to affect that doesn't seem out of line to me.<br class=""><br class="">Jim<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jul 1, 2019, at 4:00 PM, Vangelis Tsiatsianas <<a href="mailto:vangelists@icloud.com" class="">vangelists@icloud.com</a>> wrote:<br class=""><br class="">Thank you! I created the revision and added you as a reviewer (<a href="https://reviews.llvm.org/D64043" class="">https://reviews.llvm.org/D64043</a>).<br class=""><br class="">Regarding the callback mechanism, I was thinking more of components having the ability to express interest in a setting value (e.g. "target.process.thread.trace-thread") by registering a callback, which would be triggered every time a "settings set" or similar settings modification command was issued, like:<br class=""><br class="">Settings::RegisterCallback(std::string setting_value_name, std::function<void(std::string new_value)> callback);<br class=""><br class=""><br class="">That way, ThreadPlanTracer could do:<br class=""><br class="">Settings::RegisterCallback("target.process.thread.trace-thread", [](std::string new_value) {<br class=""> if (new_value == "true") {<br class=""> EnableTracing();<br class=""> } else {<br class=""> DisableTracing();<br class=""> }<br class="">});<br class=""><br class="">β¦instead of having to query the setting every time. π<br class=""><br class=""><br class="">β Vangelis<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 1 Jul 2019, at 20:18, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:<br class=""><br class="">We use <a href="http://reviews.llvm.org" class="">http://reviews.llvm.org</a><br class=""><br class="">Click on the Favorites:Differential side bar item, and then on Create Diff in the URH Corner of the window. If you make your diff with:<br class=""><br class="">svn diff --diff-cmd=diff -x -U999999<br class=""><br class="">or the git equivalent, then they are much easier to review. Once you have the diff, select make a new revision from the popup and fill out the form.<br class=""><br class=""><blockquote type="cite" class="">On Jun 29, 2019, at 11:57 PM, Vangelis Tsiatsianas <<a href="mailto:vangelists@icloud.com" class="">vangelists@icloud.com</a>> wrote:<br class=""><br class="">Thank you very much for your replies! <br class=""><br class="">I took a look at ThreadPlanTracer and found out that the crash reason was the call of a virtual method during object construction:<br class=""><br class="">virtual Process.UpdateThreadList()<br class="">βββ ProcessGDBRemote.UpdateThreadList()<br class=""> βββ new ThreadGDBRemote()<br class=""> βββ new Thread()<br class=""> βββ new ThreadPlanBase()<br class=""> βββ new ThreadPlanAssemblyTracer()<br class=""> βββ virtual ThreadPlanAssemblyTracer::EnableTracing()<br class=""> βββ virtual ThreadPlanTracer::TracingStarted()<br class=""> βββ virtual Thread::GetRegisterContext() β Virtual method call of Thread under construction!<br class=""> βββ __cxa_pure_virtual()<br class=""><br class="">I believe I fixed the bug and also tried to make the tracing API a little better.<br class=""></blockquote><br class="">Thanks! I'll take a look when it is up for review.<br class=""><br class=""><blockquote type="cite" class=""><br class="">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?<br class=""></blockquote><br class="">My intention was that you would derive from ThreadPlanTracer, and then you could do whatever reporting you wanted in the ShouldStop method of the Tracer. Kind of like what the ThreadPlanAssemblyTracer does. But I was mostly thinking of this as an internal facility. To make it available from LLDB's public face, you could do allow folks to write a scripted thread plan. But it might be simpler to just register a callback and have the extant ThreadPlanAssemblyTracer class call it in its Log method.<br class=""><br class="">Jim<br class=""><br class=""><blockquote type="cite" class=""><br class="">You may find the relevant patch attached. It was generated against llvm-8.0.0 git tag (commit SHA: d2298e74235598f15594fe2c99bbac870a507c59).<br class=""><br class=""><br class="">β Vangelis<br class=""><br class=""><br class="">P.S.: How can I submit this patch for review?<br class=""><br class=""><ThreadTracingFix.patch><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 28 Jun 2019, at 20:50, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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!<br class=""><br class="">Jim<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 28, 2019, at 7:09 AM, Ted Woodward via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">You want to set up a stop-hook.<br class=""><br class="">See βhelp target stop-hookβ, specifically βhelp target stop-hook addβ.<br class=""><br class="">target stop-hook add -o βregister read pcβ<br class="">will read the pc each time the target stops.<br class=""><br class="">From: lldb-dev <<a href="mailto:lldb-dev-bounces@lists.llvm.org" class="">lldb-dev-bounces@lists.llvm.org</a>> On Behalf Of Vangelis Tsiatsianas via lldb-dev<br class="">Sent: Friday, June 28, 2019 6:16 AM<br class="">To: via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>><br class="">Cc: Vangelis Tsiatsianas <<a href="mailto:vangelists@icloud.com" class="">vangelists@icloud.com</a>><br class="">Subject: [EXT] [lldb-dev] Enabling single-step mode and acting on each executed instruction<br class=""><br class="">Hello,<br class=""><br class="">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..<br class=""><br class="">Could you provide me with some guidance on how to accomplish it? π<br class=""><br class="">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.<br class=""><br class="">Thank you very much, in advance.<br class=""><br class=""><br class="">β Vangelis<br class=""><br class="">_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></blockquote></blockquote></blockquote></blockquote><br class=""></blockquote><br class=""></blockquote><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>