Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

I understand. Thank you very much for the thorough explanation, Jim! 🙂 ― Vangelis > On 30 Apr 2020, at 23:38, Jim Ingham wrote: > > > >> On Apr 30, 2020, at 12:43 PM, Vangelis Tsiatsianas via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >>

Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

eviates the issue, despite the sign difference. ― Vangelis > On 30 Apr 2020, at 22:22, Greg Clayton wrote: > > > >> On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Hello, >>

[lldb-dev] Question regarding argument types of "BreakpointHitCallback"

Hello, I would like to ask a question regarding "BreakpointHitCallback", which is declared as such: bool (*BreakpointHitCallback)(void *baton, StoppointCallbackContext *context, lldb::user_id_t break_id, ll

[lldb-dev] Proof of Concept for Live Reverse Debugging in LLDB

Hi everyone, I am currently finishing my master’s thesis and would like to show you what I have been working on for the past 7 months: https://github.com/vangelists/llvm-project/wiki/Reverse-Debugging The project is a proof of

Re: [lldb-dev] How to tell if an address belongs to the heap?

the stack pointer. If your address is in one of these ranges, then >> it's a stack address. Otherwise, it's probably heap (though you can never be >> 100% sure of that). >> >> However, it's not fully clear to me what it is that you're trying to do

Re: [lldb-dev] How to tell if an address belongs to the heap?

're trying to do here. > Maybe if you explain the higher level problem that you're trying to solve, we > can come up with a better solution. > > pl > > On Thu, 6 Feb 2020 at 07:40, Vangelis Tsiatsianas via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: >

[lldb-dev] How to tell if an address belongs to the heap?

Hi everyone, I am looking for a way to tell whether a memory address belongs to the heap or not. In other words, I would like to make sure that the address does not reside within any stack frame (even if the stack of the thread has been allocated in the heap) and that it’s not a global variabl

Re: [lldb-dev] Identifying instructions that definitely access memory

str::getOpcode() with TargetOpcode::G_LOAD and > TargetOpcode::G_STORE if you can obtain a MachineInstr instance. > It also may have sense to ask llvm-dev for a proper solution. > > From: lldb-dev On Behalf Of Vangelis > Tsiatsianas via lldb-dev > Sent: Tuesday, November 5, 2019 3:4

Re: [lldb-dev] Identifying instructions that definitely access memory

Hello, I decided to try once more with a follow-up email, since my previous one got no responses (I hope it’s not considered rude to send more than one message in a row for a particular question). To sum up and clarify my previous question, what I need is a way to track memory stores and save

[lldb-dev] Identifying instructions that definitely access memory

Hello, I am looking for a way to identify loads, stores and any other kind of instruction that definitely perform memory access and extract the address operand(s), however I was not able to find a cross-architecture API. The closest I stumbled upon are "MCInstrDesc::mayLoad()" and "MCInstrDesc

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

;>>> llvm-8.0.0 git tag (commit SHA: >>>>>> d2298e74235598f15594fe2c99bbac870a507c59). >>>>>> >>>>>> >>>>>> ― Vangelis >>>>>> >>>>>> >>>>>> P.S.: How can I sub

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

t 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

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

ure 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 want

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

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()     

[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

[lldb-dev] Best way to trace every executed instruction?

Hello, I would like to capture a complete execution trace of the process being debugged, i.e. save the PC of every executed instruction (preferably, in the least performance-intensive way possible), but I am not sure where to start. Using an external profiling tool or instrumentation (e.g. by i