Re: [lldb-dev] Enabling single-step mode and acting on each executed instruction

[Vangelis Tsiatsianas via lldb-dev]

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 <jing...@apple.com> 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 <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