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

[Vangelis Tsiatsianas via lldb-dev]

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:
>> 
>> Thank you for the answer, Greg.
>> 
>> I personally managed to work around the problem, although it confused me a 
>> bit at first and took a while to figure out the cause. May I suggest the 
>> addition of a note in the documentation of "{Breakpoint, 
>> Watchpoint}::{Invoke, Set}Callback()" and possibly other relevant functions 
>> as a warning to future developers that may stumble upon the same issue?
>> 
>> Regarding the public C++ API, would defining "break_id_t" as "int64_t" be a 
>> viable solution or that change would also break the API? It seems that 
>> making both types 64-bit alleviates the issue, despite the sign difference.
> 
> Mangled names don’t encode typedef names, but the bare type.  For instance:
> 
>  > cat signatures.cpp 
> #include 
> #include 
> 
> typedef int64_t break_id_t;
> 
> struct Foo {
>   void GiveMeABreak(break_id_t id) { printf("Got: %d\n", id); }
> };
> 
> int
> main()
> {
>   Foo myFoo;
>   myFoo.GiveMeABreak(100);
>   return 0;
> }
>  > clang++ -g -O0 signatures.cpp
>  > nm a.out | grep GiveMeABreak
> 00010f50 T __ZN3Foo12GiveMeABreakEx
>  > c++filt __ZN3Foo12GiveMeABreakEx
> Foo::GiveMeABreak(long long)
> 
> So this change would change the mangled names of any methods taking a 
> break_id_t, and mean old clients would get missing symbol errors when running 
> with the new API’s.  So this isn’t something we can do.
> 
> Jim
> 
> 
>> 
>> 
>> ― Vangelis
>> 
>> 
>>> On 30 Apr 2020, at 22:22, Greg Clayton >> <mailto:clayb...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev 
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>> 
>>>> 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,
>>>>   lldb::user_id_t break_loc_id);
>>>> 
>>>> Is there any particular reason that "break_id" and "break_loc_id" are of 
>>>> type "user_id_t" (64-bit unsigned) instead of "break_id_t" (32-bit 
>>>> signed), which is used both for "Stoppoint::m_bid" and 
>>>> "StoppointLocation::m_loc_id"?
>>> 
>>> I believe this callback predated the time when we added break_id and 
>>> break_loc_id, and since arguments are part of the signature of C++ 
>>> functions, we didn't change it in order to keep the public API from 
>>> changing. Or this could have just been a mistake. Either way, we have a 
>>> stable API and can't really change it.
>>>> 
>>>> This causes an issue mainly with internal breakpoints, since the callback 
>>>> of an internal breakpoint with (ID == 0xfffe) is called with (break_id 
>>>> == 0xfffe), forcing the callback to cast the argument back to 
>>>> a 32-bit signed in order to use it correctly, e.g. when the IDs are stored 
>>>> and need to be looked up.
>>>> 
>>>> A small example attempting to illustrate the problem: 
>>>> https://godbolt.org/z/y8LbK2 <https://godbolt.org/z/y8LbK2>
>>> Sorry for the issue, but I think we are stuck with it now.
>>> 
>>> 
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> <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] Question regarding argument types of "BreakpointHitCallback"

[Vangelis Tsiatsianas via lldb-dev]

Thank you for the answer, Greg.

I personally managed to work around the problem, although it confused me a bit 
at first and took a while to figure out the cause. May I suggest the addition 
of a note in the documentation of "{Breakpoint, Watchpoint}::{Invoke, 
Set}Callback()" and possibly other relevant functions as a warning to future 
developers that may stumble upon the same issue?

Regarding the public C++ API, would defining "break_id_t" as "int64_t" be a 
viable solution or that change would also break the API? It seems that making 
both types 64-bit alleviates 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,
>> 
>> 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,
>>   lldb::user_id_t break_loc_id);
>> 
>> Is there any particular reason that "break_id" and "break_loc_id" are of 
>> type "user_id_t" (64-bit unsigned) instead of "break_id_t" (32-bit signed), 
>> which is used both for "Stoppoint::m_bid" and "StoppointLocation::m_loc_id"?
> 
> I believe this callback predated the time when we added break_id and 
> break_loc_id, and since arguments are part of the signature of C++ functions, 
> we didn't change it in order to keep the public API from changing. Or this 
> could have just been a mistake. Either way, we have a stable API and can't 
> really change it.
>> 
>> This causes an issue mainly with internal breakpoints, since the callback of 
>> an internal breakpoint with (ID == 0xfffe) is called with (break_id == 
>> 0xfffe), forcing the callback to cast the argument back to a 
>> 32-bit signed in order to use it correctly, e.g. when the IDs are stored and 
>> need to be looked up.
>> 
>> A small example attempting to illustrate the problem: 
>> https://godbolt.org/z/y8LbK2 <https://godbolt.org/z/y8LbK2>
> Sorry for the issue, but I think we are stuck with it now.
> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Vangelis Tsiatsianas via lldb-dev]

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,
  lldb::user_id_t break_loc_id);

Is there any particular reason that "break_id" and "break_loc_id" are of type 
"user_id_t" (64-bit unsigned) instead of "break_id_t" (32-bit signed), which is 
used both for "Stoppoint::m_bid" and "StoppointLocation::m_loc_id"?

This causes an issue mainly with internal breakpoints, since the callback of an 
internal breakpoint with (ID == 0xfffe) is called with (break_id == 
0xfffe), forcing the callback to cast the argument back to a 32-bit 
signed in order to use it correctly, e.g. when the IDs are stored and need to 
be looked up.

A small example attempting to illustrate the problem: 
https://godbolt.org/z/y8LbK2 


― Vangelis


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Vangelis Tsiatsianas via lldb-dev]

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 concept for live reverse debugging in LLDB and is 
definitely in a very early stage, lacks plenty of features (but certainly not 
bugs ) and is currently implemented in a possibly not so ideal way, i.e. as a 
thread plan tracer.

There is still lots of room for improvement (see “Future Work” in the link 
above), however I decided to open-source it and share it with you, in case 
anyone would be interested to take a look, provide feedback or even fork and 
extend it ―changes from the LLVM project’s “master” branch are merged about 
once every few weeks, so the repository remains relatively up to date with 
recent developments.

Last but not least, the changeset can be found here: 
https://github.com/vangelists/llvm-project/compare/master...vangelists:public/reverse-debugging
 


Thank you very much for your time and all the help I received through the list 
during the development of this project, I really appreciate it! 


― Vangelis

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Vangelis Tsiatsianas via lldb-dev]

One important thing I forgot to mention in my previous email (although I 
thought I had done so) is that I am using LLDB to execute the target in 
single-step mode, thus I am already incurring the 1000x slowdown. Given that, 
the extra processing comes practically for free.

In addition, while I currently focus on Darwin on x86-64, I would prefer to 
make decisions that lead to a cross-{architecture, language, platform} 
solution, ideally without affecting the binary.

Regarding your mmap() interception suggestion, I had also considered it, but 
thought that it would require a kernel driver for handling the page faults of 
the process in order to function properly, since LD_PRELOAD / 
DYLD_INSERT_LIBRARIES wouldn’t work for programs that use syscalls directly or 
statically link with libc.

I believe that the initial solution, aka using "image lookup" and "memory 
region $sp", would better fulfil my current requirements, so I am going to give 
that a try.

Last but not least, I would like to mention that I’ve found your insights 
extremely helpful and really appreciated your willingness to help me, so thank 
you one more time! 


― Vangelis


> On 7 Feb 2020, at 19:39, Pavel Labath  wrote:
> 
> Thanks for the explanation, Vangelis.
> 
> It sounds like binary instrumentation would be the best approach for this, as 
> this is pretty much exactly what msan does. If recompilation is not an 
> option, then you might be able to get something to work via lldb, but I 
> expect this to be _incredibly_ slow (like 1000x, or more). One thing I might 
> consider in your place is some kind of a in-process solution. For instance, 
> if you intercept mmap (via LD_PRELOAD or something) then you could set it map 
> all anonymous memory (aka heap) as read-only. This way you'll get a SIGSEGV 
> everytime somebody tries to write to that address. You could intercept that 
> signal and do your analysis there. Assuming heap writes are not very common, 
> this might even give you a reasonable performance.
> 
> But this is not going to be super easy either. The trickiest part here will 
> be resuming the program -- you'll need to remap the page read-write, do a 
> single step, and then set it to read-only again.
> 
> pl
> 
> On Fri, 7 Feb 2020 at 01:40, Vangelis Tsiatsianas  <mailto:vangeli...@icloud.com>> wrote:
> Thank you for your thorough and timely response, Pavel! 
> 
> Your suggestions might actually cover completely what I am attempting to 
> achieve. 
> 
> Unfortunately, I am not able to disclose the exact reason I need it, but I 
> want to track all heap writes, in order to detect modifications in the heap 
> and save both the old and the newly written value.
> 
> For now, this translates to tracking common x86 assembly instructions (mov{l, 
> w, d, q}) for a single thread ―supporting more “exotic” instructions like 
> SIMD, multiple architectures or threads is not currently a goal.
> 
> Another method could also be an LLVM instrumentation pass, however I would 
> like to avoid recompiling and modifying the binary, thus I focus on LLDB, 
> even if I end up missing a few writes that way.
> 
> I was initially looking for a more complete, cross-platform solution (see: 
> http://lists.llvm.org/pipermail/llvm-dev/2019-November/136876.html 
> <http://lists.llvm.org/pipermail/llvm-dev/2019-November/136876.html>), but 
> the solution proved to be too time consuming for the timeframe I have 
> available for my master’s (ending in March).
> 
> 
> ― Vangelis
> 
> 
>> On 7 Feb 2020, at 01:20, Pavel Labath > <mailto:lab...@google.com>> wrote:
>> 
>> In general, getting this kind of information is pretty hard, so lldb does 
>> not offer you an out-of-the-box solution for it, but it does give you tools 
>> which you can use to approximate that.
>> 
>> If I wanted to do something like this, the first thing I'd try to do is run 
>> "image lookup -a 0xaddr". If this doesn't return anything then the address 
>> does not correspond to any known module. This rules out code, global 
>> variables, and similar. Then you can run through all of the threads and do a 
>> "memory region $SP", which will give you bounds of the memory allocation 
>> around 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 
>> 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 

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

[Vangelis Tsiatsianas via lldb-dev]

Thank you for your thorough and timely response, Pavel! 

Your suggestions might actually cover completely what I am attempting to 
achieve. 

Unfortunately, I am not able to disclose the exact reason I need it, but I want 
to track all heap writes, in order to detect modifications in the heap and save 
both the old and the newly written value.

For now, this translates to tracking common x86 assembly instructions (mov{l, 
w, d, q}) for a single thread ―supporting more “exotic” instructions like SIMD, 
multiple architectures or threads is not currently a goal.

Another method could also be an LLVM instrumentation pass, however I would like 
to avoid recompiling and modifying the binary, thus I focus on LLDB, even if I 
end up missing a few writes that way.

I was initially looking for a more complete, cross-platform solution (see: 
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136876.html 
<http://lists.llvm.org/pipermail/llvm-dev/2019-November/136876.html>), but the 
solution proved to be too time consuming for the timeframe I have available for 
my master’s (ending in March).


― Vangelis


> On 7 Feb 2020, at 01:20, Pavel Labath  wrote:
> 
> In general, getting this kind of information is pretty hard, so lldb does not 
> offer you an out-of-the-box solution for it, but it does give you tools which 
> you can use to approximate that.
> 
> If I wanted to do something like this, the first thing I'd try to do is run 
> "image lookup -a 0xaddr". If this doesn't return anything then the address 
> does not correspond to any known module. This rules out code, global 
> variables, and similar. Then you can run through all of the threads and do a 
> "memory region $SP", which will give you bounds of the memory allocation 
> around 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 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:
> 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 variable or instruction.
> 
> Checking whether it is a valid or correctly allocated address or a 
> memory-mapped file or register is not a goal, so accessing it in order to 
> decide, at the risk of causing a segmentation fault, is an accepted solution.
> 
> I have been thinking of manually checking the address against the boundaries 
> of each active stack frame, the start and end of the instruction segment and 
> the locations of all global variables.
> 
> However, I would like to ask where there are better ways to approach this 
> problem in LLDB.
> 
> Thank you very much, advance! 
> 
> 
> ― Vangelis
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> <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

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

[Vangelis Tsiatsianas via lldb-dev]

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 variable or instruction.

Checking whether it is a valid or correctly allocated address or a 
memory-mapped file or register is not a goal, so accessing it in order to 
decide, at the risk of causing a segmentation fault, is an accepted solution.

I have been thinking of manually checking the address against the boundaries of 
each active stack frame, the start and end of the instruction segment and the 
locations of all global variables.

However, I would like to ask where there are better ways to approach this 
problem in LLDB.

Thank you very much, advance! 


― Vangelis

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Vangelis Tsiatsianas via lldb-dev]

Hi Tatyana,

Thank you for your reply! 

If I understand correctly, TargetOpcode::G_{LOAD, STORE} do not cover x86’s mov 
instructions (and other relevant instructions of both x86 the rest of supported 
architectures) and such, which also access memory, however I will look into it 
more.

Additionally, thank you for the suggestion regarding llvm-dev ―I will forward 
my email to that list, too.


― Vangelis


> On 7 Nov 2019, at 13:49, Tatyana Krasnukha  
> wrote:
> 
> Hi Vangelis,
>  
> Not sure this will help you, but you can try to compare 
> llvm::MachineInstr::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:43 PM
> To: via lldb-dev 
> Cc: Vangelis Tsiatsianas 
> Subject: 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 both the old and the new value of the memory location 
> being modified.
>  
> My thinking so far:
> Recognize the instructions that definitely access memory before they execute, 
> based on their opcode.
> Tell whether each operand is a register or a memory location.
> If it’s a memory location, check whether it is a load or store destination.
> In case it is a store destination, fetch and save current value from memory.
> Execute instruction.
> Fetch and save new value from memory.
>  
> However, I was not able to find a cross-architecture API that covers all of 
> the conditions above and more specifically Instruction::DoesStore() and 
> Operand::IsStoreDestination().
>  
> Last but not least, I should notice that the target is executed in 
> single-step mode, so I do have control right before and after the execution 
> of every instruction.
>  
> Thanks, again, in advance! 
>  
>  
> ― Vangelis
>  
> 
> 
> On 21 Oct 2019, at 08:54, Vangelis Tsiatsianas  <mailto:vangeli...@icloud.com>> wrote:
>  
> 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::mayStore()", but I understand that their results are just a 
> hint, so I would then need to examine the instruction name or opcode in order 
> to find out whether it’s actually a load or store and which operand(s) is 
> (are) memory address(es) and also do so for each architecture separately, 
> which I would really like to avoid.
>  
> Is there a way to identify such instructions either by examining them through 
> the disassembler (e.g. "DoesLoad()" | "DoesStore()") before they execute or 
> right after they perform any kind of memory access?
>  
> 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

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

[Vangelis Tsiatsianas via lldb-dev]

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 both the old and the new value of the memory location 
being modified.

My thinking so far:
Recognize the instructions that definitely access memory before they execute, 
based on their opcode.
Tell whether each operand is a register or a memory location.
If it’s a memory location, check whether it is a load or store destination.
In case it is a store destination, fetch and save current value from memory.
Execute instruction.
Fetch and save new value from memory.

However, I was not able to find a cross-architecture API that covers all of the 
conditions above and more specifically Instruction::DoesStore() and 
Operand::IsStoreDestination().

Last but not least, I should notice that the target is executed in single-step 
mode, so I do have control right before and after the execution of every 
instruction.

Thanks, again, in advance! 


― Vangelis


> On 21 Oct 2019, at 08:54, Vangelis Tsiatsianas  wrote:
> 
> 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::mayStore()", but I understand that their results are just a 
> hint, so I would then need to examine the instruction name or opcode in order 
> to find out whether it’s actually a load or store and which operand(s) is 
> (are) memory address(es) and also do so for each architecture separately, 
> which I would really like to avoid.
> 
> Is there a way to identify such instructions either by examining them through 
> the disassembler (e.g. "DoesLoad()" | "DoesStore()") before they execute or 
> right after they perform any kind of memory access?
> 
> 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] Identifying instructions that definitely access memory

[Vangelis Tsiatsianas via lldb-dev]

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::mayStore()", but I understand that their results are just a hint, 
so I would then need to examine the instruction name or opcode in order to find 
out whether it’s actually a load or store and which operand(s) is (are) memory 
address(es) and also do so for each architecture separately, which I would 
really like to avoid.

Is there a way to identify such instructions either by examining them through 
the disassembler (e.g. "DoesLoad()" | "DoesStore()") before they execute or 
right after they perform any kind of memory access?

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

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

[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

[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

[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

[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

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

[Vangelis Tsiatsianas via lldb-dev]

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 injecting 
instructions in LLVM IR) is not an option.

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