> On Jul 2, 2019, at 11:52 AM, Vangelis Tsiatsianas <vangeli...@icloud.com> > wrote: > > 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.
File an enhancement request with bugs.llvm.org, otherwise it will get lost. There's also a Projects page at lldb.llvm.org 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. Jim > > Thank you, once again, for your time and very helpful responses! > > > β Vangelis > > >> On 2 Jul 2019, at 02:16, Jim Ingham <jing...@apple.com> wrote: >> >> 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. >> >> Jim >> >> >>> On Jul 1, 2019, at 4:00 PM, Vangelis Tsiatsianas <vangeli...@icloud.com> >>> wrote: >>> >>> Thank you! I created the revision and added you as a reviewer >>> (https://reviews.llvm.org/D64043). >>> >>> 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: >>> >>> Settings::RegisterCallback(std::string setting_value_name, >>> std::function<void(std::string new_value)> callback); >>> >>> >>> That way, ThreadPlanTracer could do: >>> >>> Settings::RegisterCallback("target.process.thread.trace-thread", >>> [](std::string new_value) { >>> if (new_value == "true") { >>> EnableTracing(); >>> } else { >>> DisableTracing(); >>> } >>> }); >>> >>> β¦instead of having to query the setting every time. π >>> >>> >>> β Vangelis >>> >>> >>>> On 1 Jul 2019, at 20:18, Jim Ingham <jing...@apple.com> wrote: >>>> >>>> We use http://reviews.llvm.org >>>> >>>> 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: >>>> >>>> svn diff --diff-cmd=diff -x -U999999 >>>> >>>> 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. >>>> >>>>> On Jun 29, 2019, at 11:57 PM, Vangelis Tsiatsianas >>>>> <vangeli...@icloud.com> wrote: >>>>> >>>>> 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. >>>> >>>> Thanks! I'll take a look when it is up for review. >>>> >>>>> >>>>> 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? >>>> >>>> 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. >>>> >>>> Jim >>>> >>>>> >>>>> 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? >>>>> >>>>> <ThreadTracingFix.patch> >>>>> >>>>> >>>>>> On 28 Jun 2019, at 20:50, Jim Ingham <jing...@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@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-boun...@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@lists.llvm.org> >>>>>>> Cc: Vangelis Tsiatsianas <vangeli...@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@lists.llvm.org >>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
