<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 <stdio.h> and see how that goes? <div class=""><br class=""></div><div class="">The better way to do what you want is to write a shared library, save it to "/tmp/liba.so" and then load it at runtime:<div class=""><br class=""></div><div class="">(lldb) process load /tmp/liba.so</div><div class=""><br class=""></div><div class="">This will load a shared library with all of the top level code you want into your current program, then you can call any functions in that shared library as well using expressions that you need.</div><div class=""><br class=""></div><div class="">If you feel you still need to use the expression parser, then a few tips on the expression parser when not in top level code mode:</div><div class="">- C++ lambda functions that don't capture anything can be cast to function pointer types and used as static callbacks.</div><div class="">- Any variable you define that is prefixed with a '$' will become a global variable and persist beyond your expression (assign a function callback from C++ lambda, and you have a callback you can now use.</div><div class="">- Any type you declare that is prefixed with a '$' will persist beyond that expression and be available for future expressions.</div><div class="">- Any type returned as the result type of an expression will have its type available</div><div class=""><br class=""></div><div class="">Greg</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 13, 2017, at 6:00 AM, Roman Popov via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thats nice! But how to enable C++?:<div class=""><br class=""></div><div class=""><div class="">(lldb) expr --top-level --</div><div class="">Enter expressions, then terminate with an empty line to evaluate:</div><div class="">1 #include <iostream></div><div class="">2 void HOOK() { std::cout << "in hook\n"; }</div><div class="">3 </div></div><div class=""><br class=""></div><div class=""><div class="">error: 'iostream' file not found</div></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-02-13 16:46 GMT+03:00 Pavel Labath <span dir="ltr" class=""><<a href="mailto:labath@google.com" target="_blank" class="">labath@google.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Try this for size:<br class="">
<br class="">
<br class="">
$ bin/lldb /tmp/a.out<br class="">
(lldb) target create "/tmp/a.out"<br class="">
Current executable set to '/tmp/a.out' (x86_64).<br class="">
(lldb) b main<br class="">
Breakpoint 1: where = a.out`main + 4 at <a href="http://a.cc" class="">a.cc</a>:6, address = 0x0000000000400531<br class="">
(lldb) pr la<br class="">
Process 22550 launched: '/tmp/a.out' (x86_64)<br class="">
Process 22550 stopped<br class="">
* thread #1, name = 'a.out', stop reason = breakpoint 1.1<br class="">
frame #0: 0x0000000000400531 a.out`main at <a href="http://a.cc" class="">a.cc</a>:6<br class="">
3 void (* volatile hook)();<br class="">
4<br class="">
5 int main() {<br class="">
-> 6 printf("before\n");<br class="">
7 if(hook) hook();<br class="">
8 printf("after\n");<br class="">
9 }<br class="">
(lldb) expr --top-level -- void HOOK() { (int)printf("in hook\n"); }<br class="">
(lldb) expr hook = &HOOK<br class="">
(void (*volatile)()) $0 = 0x00007ffff7ff5030<br class="">
(lldb) c<br class="">
Process 22550 resuming<br class="">
before<br class="">
in hook<br class="">
after<br class="">
Process 22550 exited with status = 0 (0x00000000)<br class="">
(lldb)<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
<br class="">
On 13 February 2017 at 13:38, Roman Popov <<a href="mailto:ripopov@gmail.com" class="">ripopov@gmail.com</a>> wrote:<br class="">
> Yes, it would fit. I can even insert hooks manually, like:<br class="">
><br class="">
> std::function<void()> instrumentation_hook = []{ /*dear lldb script, please<br class="">
> insert your code here*/ }<br class="">
><br class="">
> instrumentation_hook(); // run instrumentation, by default does nothing.<br class="">
><br class="">
><br class="">
> Is there an easy way to compile some code in lldb and assign to<br class="">
> instrumentation_hook ?<br class="">
><br class="">
><br class="">
> 2017-02-13 16:33 GMT+03:00 Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>>:<br class="">
>><br class="">
>> Making the code persist is easy - that's sort of what expr --top-level<br class="">
>> does.<br class="">
>><br class="">
>> The tricky part is getting your code to execute. When you evaluate<br class="">
>> expressions interactively, we manually modify the registers (PC being<br class="">
>> the most important one) to point to the code you want to execute. If<br class="">
>> you want it to happen automatically at runtime, you would have to<br class="">
>> insert a jump instruction somewhere. The problem is, that can't<br class="">
>> usually be done without overwriting a couple of instructions of<br class="">
>> original code, which means you then have to somehow simulate the<br class="">
>> effects of the overwritten instructions. And there's always a danger<br class="">
>> that you will overwrite a jump target and things will blow up when<br class="">
>> someone tries to jump there. The way this is normally done is that you<br class="">
>> have the compiler insert hooks into your code during compilation, that<br class="">
>> you can then intercept if necessary. I am not sure if that would fit<br class="">
>> your use case.<br class="">
>><br class="">
>> pl<br class="">
>><br class="">
>><br class="">
>><br class="">
>> On 13 February 2017 at 13:13, Roman Popov <<a href="mailto:ripopov@gmail.com" class="">ripopov@gmail.com</a>> wrote:<br class="">
>> > Thanks Pavel, you are correct. This was the direction I thought to<br class="">
>> > investigate, but I didnt done my homework yet.<br class="">
>> ><br class="">
>> > Yes, dynamic instrumentation is what I want. Looks like both lldb and<br class="">
>> > gdb do<br class="">
>> > not allow this directly.<br class="">
>> ><br class="">
>> > As GDB doc says "After execution, the compiled code is removed from gdb<br class="">
>> > and<br class="">
>> > any new types or variables you have defined will be deleted."<br class="">
>> ><br class="">
>> > Do you know why it is the case? Why cannot my generated code persist?<br class="">
>> ><br class="">
>> ><br class="">
>> > Looks like technically it is possible. For example you can allocate<br class="">
>> > memory<br class="">
>> > for generated code on heap.<br class="">
>> ><br class="">
>> > GDB does not even allow me to define a new function. But for data<br class="">
>> > dynamic<br class="">
>> > allocation works perfectly fine:<br class="">
>> ><br class="">
>> ><br class="">
>> > Example:<br class="">
>> ><br class="">
>> > #include <stdio.h><br class="">
>> ><br class="">
>> > char message[1000] = "test message\n";<br class="">
>> ><br class="">
>> > int main() {<br class="">
>> > char *msg = message;<br class="">
>> ><br class="">
>> > for (int i = 0; i < 5; i++)<br class="">
>> > printf("%s\n", msg);<br class="">
>> ><br class="">
>> > return 0;<br class="">
>> > }<br class="">
>> ><br class="">
>> ><br class="">
>> ><br class="">
>> > gdb session:<br class="">
>> ><br class="">
>> > (gdb) break main.c:8<br class="">
>> > Breakpoint 1 at 0x400536: file main.c, line 8.<br class="">
>> > (gdb) run<br class="">
>> > Starting program: /home/ripopov/work/test_c_<wbr class="">inject/a.out<br class="">
>> ><br class="">
>> > Breakpoint 1, main () at main.c:8<br class="">
>> > 8 for (int i = 0; i < 5; i++)<br class="">
>> > (gdb) compile code<br class="">
>> >>char *str;<br class="">
>> >>str = (char *) malloc(3);<br class="">
>> >>str[0] = 'T';<br class="">
>> >>str[1] = '\n';<br class="">
>> >>str[2] = 0;<br class="">
>> >>msg = str;<br class="">
>> >>end<br class="">
>> > (gdb) c<br class="">
>> > Continuing.<br class="">
>> > T<br class="">
>> ><br class="">
>> > T<br class="">
>> ><br class="">
>> > T<br class="">
>> ><br class="">
>> > T<br class="">
>> ><br class="">
>> > T<br class="">
>> ><br class="">
>> > [Inferior 1 (process 96445) exited normally]<br class="">
>> > (gdb)<br class="">
>> ><br class="">
>> ><br class="">
>> ><br class="">
>> ><br class="">
>> > 2017-02-13 13:56 GMT+03:00 Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>>:<br class="">
>> >><br class="">
>> >> Every time you use the "expr" command, we compile a tiny c++ code<br class="">
>> >> snippet inject it into the target process and execute it. If you type<br class="">
>> >> "log enable lldb expr" you should be able to follow how exactly that<br class="">
>> >> works. You can use pretty much any c++ construct in the expression<br class="">
>> >> including declaring variables/types:<br class="">
>> >> (lldb) expr -- char s[]="qwerty"; for(int i=0; i < sizeof s; ++i)<br class="">
>> >> printf("%d: %c\n", i, s[i]);<br class="">
>> >> 0: q<br class="">
>> >> 1: w<br class="">
>> >> 2: e<br class="">
>> >> 3: r<br class="">
>> >> 4: t<br class="">
>> >> 5: y<br class="">
>> >> 6:<br class="">
>> >><br class="">
>> >><br class="">
>> >> So, if your question is "do we support compiling code and running it<br class="">
>> >> in the debugged process", then the answer is yes. If you want<br class="">
>> >> something that would automatically intercept some function to execute<br class="">
>> >> your code while the process is running (some kind of dynamic<br class="">
>> >> instrumentation), then the answer is no. (But I don't see any mention<br class="">
>> >> of that on the gdb page you quoted either).<br class="">
>> >><br class="">
>> >> cheers,<br class="">
>> >> pavel<br class="">
>> >><br class="">
>> >> On 12 February 2017 at 18:34, Roman Popov via lldb-dev<br class="">
>> >> <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:<br class="">
>> >> > Hello Benjamin , all<br class="">
>> >> ><br class="">
>> >> >>>I recently started using lldb to write a basic instrumentation tool<br class="">
>> >> >>> for<br class="">
>> >> >>>tracking the values of variables at various code-points in a<br class="">
>> >> >>> program.<br class="">
>> >> ><br class="">
>> >> > I have the same problem of tracing some variables and debugging<br class="">
>> >> > application<br class="">
>> >> > post-mortem. Without knowing about your experience I've started<br class="">
>> >> > walking<br class="">
>> >> > same<br class="">
>> >> > path and encountered same problem. In my case inserting an empty<br class="">
>> >> > callback<br class="">
>> >> > slows-down application by 100x. This is not acceptable for me,<br class="">
>> >> > because<br class="">
>> >> > instead of minutes I got hours of runtime.<br class="">
>> >> ><br class="">
>> >> > Did you found any faster solution?<br class="">
>> >> ><br class="">
>> >> > My current plan is to solve it with code injection: I plan to find<br class="">
>> >> > pointers<br class="">
>> >> > to interesting values using debugger scripting and then inject code<br class="">
>> >> > to<br class="">
>> >> > trace<br class="">
>> >> > them.<br class="">
>> >> ><br class="">
>> >> > Does LLDB supports code injection ? I've found information only about<br class="">
>> >> > gdb<br class="">
>> >> ><br class="">
>> >> ><br class="">
>> >> > <a href="https://sourceware.org/gdb/onlinedocs/gdb/Compiling-and-Injecting-Code.html" rel="noreferrer" target="_blank" class="">https://sourceware.org/gdb/<wbr class="">onlinedocs/gdb/Compiling-and-<wbr class="">Injecting-Code.html</a><br class="">
>> >> > but not about lldb<br class="">
>> >> ><br class="">
>> >> ><br class="">
>> >> > -Roman<br class="">
>> >> ><br class="">
>> >> ><br class="">
>> >> > ______________________________<wbr class="">_________________<br class="">
>> >> > lldb-dev mailing list<br class="">
>> >> > <a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">
>> >> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/lldb-dev</a><br class="">
>> >> ><br class="">
>> ><br class="">
>> ><br class="">
><br class="">
><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>