Thank you! I created the revision and added you as a reviewer
(https://reviews.llvm.org/D64043 <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 <[email protected]> wrote:
>
> We use http://reviews.llvm.org <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 <[email protected]>
>> 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 <[email protected]> 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
>>>> <[email protected]> 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 <[email protected]> On Behalf Of Vangelis
>>>> Tsiatsianas via lldb-dev
>>>> Sent: Friday, June 28, 2019 6:16 AM
>>>> To: via lldb-dev <[email protected]>
>>>> Cc: Vangelis Tsiatsianas <[email protected]>
>>>> 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
>>>> [email protected]
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
