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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo