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

[Vangelis Tsiatsianas via lldb-dev]

acing 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?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 28 Jun 2019, at 20:50, Jim Ingham  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 
>>>>>>>>  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  On Behalf Of Vangelis 
>>>>>>>> Tsiatsianas via lldb-dev
>>>>>>>> Sent: Friday, June 28, 2019 6:16 AM
>>>>>>>> To: via lldb-dev 
>>>>>>>> Cc: Vangelis Tsiatsianas 
>>>>>>>> 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

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

[Jim Ingham via lldb-dev]

ouldn’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?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 28 Jun 2019, at 20:50, Jim Ingham  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 
>>>>>>>  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  On Behalf Of Vangelis 
>>>>>>> Tsiatsianas via lldb-dev
>>>>>>> Sent: Friday, June 28, 2019 6:16 AM
>>>>>>> To: via lldb-dev 
>>>>>>> Cc: Vangelis Tsiatsianas 
>>>>>>> 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

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

[Vangelis Tsiatsianas via lldb-dev]

;>>> llvm-8.0.0 git tag (commit SHA: d2298e74235598f15594fe2c99bbac870a507c59).
>>>> 
>>>> 
>>>> ― Vangelis
>>>> 
>>>> 
>>>> P.S.: How can I submit this patch for review?
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 28 Jun 2019, at 20:50, Jim Ingham  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 
>>>>>>  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  On Behalf Of Vangelis 
>>>>>> Tsiatsianas via lldb-dev
>>>>>> Sent: Friday, June 28, 2019 6:16 AM
>>>>>> To: via lldb-dev 
>>>>>> Cc: Vangelis Tsiatsianas 
>>>>>> 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

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

[Jim Ingham via lldb-dev]

he 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 
>>>>>  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  On Behalf Of Vangelis 
>>>>> Tsiatsianas via lldb-dev
>>>>> Sent: Friday, June 28, 2019 6:16 AM
>>>>> To: via lldb-dev 
>>>>> Cc: Vangelis Tsiatsianas 
>>>>> 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

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

[Vangelis Tsiatsianas via lldb-dev]

;>> 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 
>>>>  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  On Behalf Of Vangelis 
>>>> Tsiatsianas via lldb-dev
>>>> Sent: Friday, June 28, 2019 6:16 AM
>>>> To: via lldb-dev 
>>>> Cc: Vangelis Tsiatsianas 
>>>> 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

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

[Jim Ingham via lldb-dev]

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

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  
> 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?
> 
> 
> 
> 
>> On 28 Jun 2019, at 20:50, Jim Ingham  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 
>>>  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  On Behalf Of Vangelis 
>>> Tsiatsianas via lldb-dev
>>> Sent: Friday, June 28, 2019 6:16 AM
>>> To: via lldb-dev 
>>> Cc: Vangelis Tsiatsianas 
>>> 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

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

[Vangelis Tsiatsianas via lldb-dev]

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.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?You may find the relevant patch attached. It was generated against llvm-8.0.0 git tag (commit SHA: d2298e74235598f15594fe2c99bbac870a507c59).― VangelisP.S.: How can I submit this patch for review?

ThreadTracingFix.patch
Description: Binary data
On 28 Jun 2019, at 20:50, Jim Ingham  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!JimOn Jun 28, 2019, at 7:09 AM, Ted Woodward via lldb-dev  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  On Behalf Of Vangelis Tsiatsianas via lldb-devSent: Friday, June 28, 2019 6:16 AMTo: via lldb-dev Cc: Vangelis Tsiatsianas Subject: [EXT] [lldb-dev] Enabling single-step mode and acting on each executed instructionHello,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 listlldb-dev@lists.llvm.orghttps://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

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

[Jim Ingham via lldb-dev]

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 
>  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  On Behalf Of Vangelis 
> Tsiatsianas via lldb-dev
> Sent: Friday, June 28, 2019 6:16 AM
> To: via lldb-dev 
> Cc: Vangelis Tsiatsianas 
> 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

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

[Ted Woodward via lldb-dev]

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  On Behalf Of Vangelis 
Tsiatsianas via lldb-dev
Sent: Friday, June 28, 2019 6:16 AM
To: via lldb-dev 
Cc: Vangelis Tsiatsianas 
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] Enabling single-step mode and acting on each executed instruction

[Vangelis Tsiatsianas via lldb-dev]

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