Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Roman Popov via lldb-dev
Thank you very much Greg and Pavel for help! I will probably need another months or so to work on my variable tracing stuff. I don't see any additional roadblocks yet. 2017-02-13 22:11 GMT+03:00 Greg Clayton : > Clang just doesn't currently know where to look for the

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Greg Clayton via lldb-dev
Clang just doesn't currently know where to look for the standard headers. Not sure if this is a top level code only bug or not. I know the expression parser can include common C headers on Darwin. Not sure if any includes work on linux. Try importing and see how that goes? The better way to

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Roman Popov via lldb-dev
Thats nice! But how to enable C++?: (lldb) expr --top-level -- Enter expressions, then terminate with an empty line to evaluate: 1 #include 2 void HOOK() { std::cout << "in hook\n"; } 3 error: 'iostream' file not found 2017-02-13 16:46 GMT+03:00 Pavel Labath : > Try this

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Pavel Labath via lldb-dev
Try this for size: $ bin/lldb /tmp/a.out (lldb) target create "/tmp/a.out" Current executable set to '/tmp/a.out' (x86_64). (lldb) b main Breakpoint 1: where = a.out`main + 4 at a.cc:6, address = 0x00400531 (lldb) pr la Process 22550 launched: '/tmp/a.out' (x86_64) Process 22550 stopped

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Roman Popov via lldb-dev
Yes, it would fit. I can even insert hooks manually, like: std::function instrumentation_hook = []{ /*dear lldb script, please insert your code here*/ } instrumentation_hook(); // run instrumentation, by default does nothing. Is there an easy way to compile some code in lldb and

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Pavel Labath via lldb-dev
Making the code persist is easy - that's sort of what expr --top-level does. The tricky part is getting your code to execute. When you evaluate expressions interactively, we manually modify the registers (PC being the most important one) to point to the code you want to execute. If you want it to

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-13 Thread Pavel Labath via lldb-dev
Every time you use the "expr" command, we compile a tiny c++ code snippet inject it into the target process and execute it. If you type "log enable lldb expr" you should be able to follow how exactly that works. You can use pretty much any c++ construct in the expression including declaring

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2017-02-12 Thread Roman Popov via lldb-dev
Hello Benjamin , all >>I recently started using lldb to write a basic instrumentation tool for >>tracking the values of variables at various code-points in a program. I have the same problem of tracing some variables and debugging application post-mortem. Without knowing about your experience

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2016-08-17 Thread Pavel Labath via lldb-dev
Hello Benjamin, all, the lldb-server implementation in linux works exactly the same way as debugserver does on osx -- it runs out of process and uses sockets to communicate with the client. The socketpair() optimization that Jim is talking about is not enabled there yet - I want to do some

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2016-08-16 Thread Benjamin Dicken via lldb-dev
On Tue, Aug 16, 2016 at 11:06 AM, Jim Ingham wrote: > > > On Aug 16, 2016, at 10:42 AM, Benjamin Dicken < > bddic...@datawareventures.com> wrote: > > > > Thanks for the quick reply. > > > > > Are you sure the actual handling of the breakpoint & callback in lldb > is what is

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2016-08-16 Thread Benjamin Dicken via lldb-dev
Thanks for the quick reply. > Are you sure the actual handling of the breakpoint & callback in lldb is what is taking most of the time? I'm not positive. I did collect some callgrind profiles to take a look at where most of the time is being spent, but i'm not very familiar with lldb internals

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2016-08-16 Thread Jim Ingham via lldb-dev
Are you sure the actual handling of the breakpoint & callback in lldb is what is taking most of the time? The last time we looked at this, the majority of the work was in communicating with debugserver to get the stop notification and restart. Note, besides all the packet code, this involves

[lldb-dev] Breakpoint + callback performance ... Can it be faster?

2016-08-16 Thread Benjamin Dicken via lldb-dev
I recently started using lldb to write a basic instrumentation tool for tracking the values of variables at various code-points in a program. I've been working with lldb for less than two weeks, so I am pretty new. Though, I have used and written llvm passes in the past, so I'm familiar with the