<div dir="ltr">Thanks Pavel, you are correct. This was the direction I thought to investigate, but I didnt done my homework yet.<div><br></div><div>Yes, dynamic instrumentation is what I want. Looks like both lldb and gdb do not allow this directly.</div><div><br></div><div>As GDB doc says "<span style="color:rgb(0,0,0);font-family:"times new roman";font-size:medium">After execution, the compiled code is removed from </span><span class="gmail-sc" style="color:rgb(0,0,0);font-family:"times new roman";font-size:medium">gdb</span><span style="color:rgb(0,0,0);font-family:"times new roman";font-size:medium"> and any new types or variables you have defined will be deleted.</span>"</div><div><br></div><div>Do you know why it is the case? Why cannot my generated code persist?</div><div><br></div><div><br></div><div>Looks like technically it is possible. For example you can allocate memory for generated code on heap. </div><div><br></div><div><div>GDB does not even allow me to define a new function. But for data dynamic allocation works perfectly fine:</div></div><div><br></div><div><br></div><div>Example:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>#include <stdio.h></div></div><div><div><br></div></div><div><div>char message[1000] = "test message\n";</div></div><div><div><br></div></div><div><div>int main() {</div></div><div><div>    char *msg = message;</div></div><div><div><br></div></div><div><div>    for (int i = 0; i < 5; i++)</div></div><div><div>        printf("%s\n", msg);</div></div><div><div><br></div></div><div><div>    return 0;</div></div><div><div>}</div></div></blockquote><div><br></div><div><br></div><div>gdb session:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>(gdb) break main.c:8</div></div><div><div>Breakpoint 1 at 0x400536: file main.c, line 8.</div></div><div><div>(gdb) run</div></div><div><div>Starting program: /home/ripopov/work/test_c_inject/a.out </div></div><div><div><br></div></div><div><div>Breakpoint 1, main () at main.c:8</div></div><div><div>8           for (int i = 0; i < 5; i++)</div></div><div><div>(gdb) compile code</div></div><div><div>>char *str;</div></div><div><div>>str = (char *) malloc(3);</div></div><div><div>>str[0] = 'T';</div></div><div><div>>str[1] = '\n';</div></div><div><div>>str[2] = 0;</div></div><div><div>>msg = str;</div></div><div><div>>end</div></div><div><div>(gdb) c</div></div><div><div>Continuing.</div></div><div><div>T</div></div><div><div><br></div></div><div><div>T</div></div><div><div><br></div></div><div><div>T</div></div><div><div><br></div></div><div><div>T</div></div><div><div><br></div></div><div><div>T</div></div><div><div><br></div></div><div><div>[Inferior 1 (process 96445) exited normally]</div></div><div><div>(gdb) </div></div></blockquote><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-13 13:56 GMT+03:00 Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Every time you use the "expr" command, we compile a tiny c++ code<br>
snippet inject it into the target process and execute it. If you type<br>
"log enable lldb expr" you should be able to follow how exactly that<br>
works. You can use pretty much any c++ construct in the expression<br>
including declaring variables/types:<br>
(lldb) expr -- char s[]="qwerty"; for(int i=0; i < sizeof s; ++i)<br>
printf("%d: %c\n", i, s[i]);<br>
0: q<br>
1: w<br>
2: e<br>
3: r<br>
4: t<br>
5: y<br>
6:<br>
<br>
<br>
So, if your question is "do we support compiling code and running it<br>
in the debugged process", then the answer is yes. If you want<br>
something that would automatically intercept some function to execute<br>
your code while the process is running (some kind of dynamic<br>
instrumentation), then the answer is no. (But I don't see any mention<br>
of that on the gdb page you quoted either).<br>
<br>
cheers,<br>
pavel<br>
<br>
On 12 February 2017 at 18:34, Roman Popov via lldb-dev<br>
<div><div class="h5"><<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> Hello Benjamin , all<br>
><br>
>>>I recently started using lldb to write a basic instrumentation tool for<br>
>>>tracking the values of variables at various code-points in a program.<br>
><br>
> I have the same problem of tracing some variables and debugging application<br>
> post-mortem. Without knowing about your experience I've started walking same<br>
> path and encountered same problem. In my case inserting an empty callback<br>
> slows-down application by 100x. This is not acceptable for me, because<br>
> instead of minutes I got hours of runtime.<br>
><br>
> Did you found any faster solution?<br>
><br>
> My current plan is to solve it with code injection: I plan to find pointers<br>
> to interesting values using debugger scripting and then inject code to trace<br>
> them.<br>
><br>
> Does LLDB supports code injection ? I've found information only about gdb<br>
> <a href="https://sourceware.org/gdb/onlinedocs/gdb/Compiling-and-Injecting-Code.html" rel="noreferrer" target="_blank">https://sourceware.org/gdb/<wbr>onlinedocs/gdb/Compiling-and-<wbr>Injecting-Code.html</a><br>
> but not about lldb<br>
><br>
><br>
> -Roman<br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
><br>
</blockquote></div><br></div>