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

[Roman Popov via lldb-dev]

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170213/d76e03f7/attachment.html>