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

[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 happen automatically at runtime, you would have to
insert a jump instruction somewhere. The problem is, that can't
usually be done without overwriting a couple of instructions of
original code, which means you then have to somehow simulate the
effects of the overwritten instructions. And there's always a danger
that you will overwrite a jump target and things will blow up when
someone tries to jump there. The way this is normally done is that you
have the compiler insert hooks into your code during compilation, that
you can then intercept if necessary. I am not sure if that would fit
your use case.

pl



On 13 February 2017 at 13:13, Roman Popov <ripopov at gmail.com> wrote:
> Thanks Pavel, you are correct. This was the direction I thought to
> investigate, but I didnt done my homework yet.
>
> Yes, dynamic instrumentation is what I want. Looks like both lldb and gdb do
> not allow this directly.
>
> As GDB doc says "After execution, the compiled code is removed from gdb and
> any new types or variables you have defined will be deleted."
>
> Do you know why it is the case? Why cannot my generated code persist?
>
>
> Looks like technically it is possible. For example you can allocate memory
> for generated code on heap.
>
> GDB does not even allow me to define a new function. But for data dynamic
> allocation works perfectly fine:
>
>
> Example:
>
> #include <stdio.h>
>
> char message[1000] = "test message\n";
>
> int main() {
>     char *msg = message;
>
>     for (int i = 0; i < 5; i++)
>         printf("%s\n", msg);
>
>     return 0;
> }
>
>
>
> gdb session:
>
> (gdb) break main.c:8
> Breakpoint 1 at 0x400536: file main.c, line 8.
> (gdb) run
> Starting program: /home/ripopov/work/test_c_inject/a.out
>
> Breakpoint 1, main () at main.c:8
> 8           for (int i = 0; i < 5; i++)
> (gdb) compile code
>>char *str;
>>str = (char *) malloc(3);
>>str[0] = 'T';
>>str[1] = '\n';
>>str[2] = 0;
>>msg = str;
>>end
> (gdb) c
> Continuing.
> T
>
> T
>
> T
>
> T
>
> T
>
> [Inferior 1 (process 96445) exited normally]
> (gdb)
>
>
>
>
> 2017-02-13 13:56 GMT+03:00 Pavel Labath <labath at google.com>:
>>
>> 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 variables/types:
>> (lldb) expr -- char s[]="qwerty"; for(int i=0; i < sizeof s; ++i)
>> printf("%d: %c\n", i, s[i]);
>> 0: q
>> 1: w
>> 2: e
>> 3: r
>> 4: t
>> 5: y
>> 6:
>>
>>
>> So, if your question is "do we support compiling code and running it
>> in the debugged process", then the answer is yes. If you want
>> something that would automatically intercept some function to execute
>> your code while the process is running (some kind of dynamic
>> instrumentation), then the answer is no. (But I don't see any mention
>> of that on the gdb page you quoted either).
>>
>> cheers,
>> pavel
>>
>> On 12 February 2017 at 18:34, Roman Popov via lldb-dev
>> <lldb-dev at lists.llvm.org> wrote:
>> > 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 I've started walking
>> > same
>> > path and encountered same problem. In my case inserting an empty
>> > callback
>> > slows-down application by 100x. This is not acceptable for me, because
>> > instead of minutes I got hours of runtime.
>> >
>> > Did you found any faster solution?
>> >
>> > My current plan is to solve it with code injection: I plan to find
>> > pointers
>> > to interesting values using debugger scripting and then inject code to
>> > trace
>> > them.
>> >
>> > Does LLDB supports code injection ? I've found information only about
>> > gdb
>> >
>> > https://sourceware.org/gdb/onlinedocs/gdb/Compiling-and-Injecting-Code.html
>> > but not about lldb
>> >
>> >
>> > -Roman
>> >
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>
>