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.
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
