I will to do so, starting with bugs.llvm.org <http://bugs.llvm.org/>. Thank you! π
β Vangelis > On 2 Jul 2019, at 23:09, Jim Ingham <jing...@apple.com> wrote: > > > >> 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
