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

[Pavel Labath via lldb-dev]

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
 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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [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 

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 :

> 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
>  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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [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  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 
>
> 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 :
>>
>> 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
>>  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@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Roman Popov via lldb-dev]

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 assign to
instrumentation_hook ?


2017-02-13 16:33 GMT+03:00 Pavel Labath :

> 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  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 
> >
> > 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 :
> >>
> >> 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
> >>  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
> >

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

[Pavel Labath via lldb-dev]

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
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400531 a.out`main at a.cc:6
   3   void (* volatile hook)();
   4
   5   int main() {
-> 6printf("before\n");
   7if(hook) hook();
   8printf("after\n");
   9   }
(lldb) expr --top-level -- void HOOK() { (int)printf("in hook\n"); }
(lldb) expr hook = &HOOK
(void (*volatile)()) $0 = 0x77ff5030
(lldb) c
Process 22550 resuming
before
in hook
after
Process 22550 exited with status = 0 (0x)
(lldb)


On 13 February 2017 at 13:38, Roman Popov  wrote:
> 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 assign to
> instrumentation_hook ?
>
>
> 2017-02-13 16:33 GMT+03:00 Pavel Labath :
>>
>> 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  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 
>> >
>> > 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 :
>> >>
>> >> 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
>> >>  wrote:
>> >> > Hello Benjamin , 

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

[Roman Popov via lldb-dev]

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 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
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400531 a.out`main at a.cc:6
>3   void (* volatile hook)();
>4
>5   int main() {
> -> 6printf("before\n");
>7if(hook) hook();
>8printf("after\n");
>9   }
> (lldb) expr --top-level -- void HOOK() { (int)printf("in hook\n"); }
> (lldb) expr hook = &HOOK
> (void (*volatile)()) $0 = 0x77ff5030
> (lldb) c
> Process 22550 resuming
> before
> in hook
> after
> Process 22550 exited with status = 0 (0x)
> (lldb)
>
>
> On 13 February 2017 at 13:38, Roman Popov  wrote:
> > 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 assign to
> > instrumentation_hook ?
> >
> >
> > 2017-02-13 16:33 GMT+03:00 Pavel Labath :
> >>
> >> 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  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 
> >> >
> >> > 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 :
> >> >>
> >> >> 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:

Re: [lldb-dev] Python example does not work with latest LLDBs

[Greg Clayton via lldb-dev]

The example code is:

#!/usr/bin/python

import lldb
import os

def disassemble_instructions(insts):
for i in insts:
print i

# Set the path to the executable to debug
exe = "./a.out"

# Create a new debugger instance
debugger = lldb.SBDebugger.Create()

# When we step or continue, don't return from the function until the process 
# stops. Otherwise we would have to handle the process events ourselves which, 
while doable is
#a little tricky.  We do this by setting the async mode to false.
debugger.SetAsync (False)

# Create a target from a file and arch
print "Creating a target for '%s'" % exe

target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)

if target:
# If the target is valid set a breakpoint at main
main_bp = target.BreakpointCreateByName ("main", 
target.GetExecutable().GetFilename());

print main_bp

# Launch the process. Since we specified synchronous mode, we won't return
# from this function until we hit the breakpoint at main
process = target.LaunchSimple (None, None, os.getcwd())

# Make sure the launch went ok
if process:
# Print some simple process info
state = process.GetState ()
print process
if state == lldb.eStateStopped:
# Get the first thread
thread = process.GetThreadAtIndex (0)
if thread:
# Print some simple thread info
print thread
# Get the first frame
frame = thread.GetFrameAtIndex (0)
if frame:
# Print some simple frame info
print frame
function = frame.GetFunction()
# See if we have debug info (a function)
if function:
# We do have a function, print some info for the 
function
print function
# Now get all instructions for this function and print 
them
insts = function.GetInstructions(target)
disassemble_instructions (insts)
else:
# See if we have a symbol in the symbol table for where 
we stopped
symbol = frame.GetSymbol();
if symbol:
# We do have a symbol, print some info for the 
symbol
print symbol

We set the async mode to false, so target.LaunchSimple() should not return 
until the process is stopped or exited. Note in your example it is returning 
with "state = launching", so this is what is failing. For some reason 
synchronous mode is not being obeyed.

Greg

> On Feb 11, 2017, at 10:07 AM, Roman Popov via lldb-dev 
>  wrote:
> 
> I'm testing example from https://lldb.llvm.org/python-reference.html 
>  (USING THE LLDB.PY MODULE IN 
> PYTHON)  on Ubuntu 16.04
> 
> For some reason it works only with LLDB 3.9, is it because LLDB 4.0/5.0 are 
> not stable yet?
> 
> #5.0   -- Does not work
> deb http://apt.llvm.org/xenial/  
> llvm-toolchain-xenial main
> # 3.9  -- Works
> deb http://apt.llvm.org/xenial/  
> llvm-toolchain-xenial-3.9 main
> # 4.0  -- Does not work
> deb http://apt.llvm.org/xenial/  
> llvm-toolchain-xenial-4.0 main
> 
> >clang-5.0 -g test.cpp
> >./python_example.py
> Creating a target for './a.out'
> SBBreakpoint: id = 1, name = 'main', locations = 1
> SBProcess: pid = 0, state = launching, threads = 0, executable = a.out
> Thanks,
> Roman
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python example does not work with latest LLDBs

[Roman Popov via lldb-dev]

Yes Greg, this was my expectation that it should not return until stops on
break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9 to
make it work as expected.

Can I get some diagnostics? Any log files?

2017-02-13 20:11 GMT+03:00 Greg Clayton :

> The example code is:
>
> #!/usr/bin/python
>
> import lldb
> import os
>
> def disassemble_instructions(insts):
> for i in insts:
> print i
> # Set the path to the executable to debug
> exe = "./a.out"
> # Create a new debugger instance
> debugger = lldb.SBDebugger.Create()
> # When we step or continue, don't return from the function until the process
> # stops. Otherwise we would have to handle the process events ourselves 
> which, while doable is
> #a little tricky.  We do this by setting the async mode to false.
> debugger.SetAsync (False)
> # Create a target from a file and arch
> print "Creating a target for '%s'" % exe
>
> target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
>
> if target:
> # If the target is valid set a breakpoint at main
> main_bp = target.BreakpointCreateByName ("main", 
> target.GetExecutable().GetFilename());
>
> print main_bp
>
> # Launch the process. Since we specified synchronous mode, we won't return
> # from this function until we hit the breakpoint at main
> process = target.LaunchSimple (None, None, os.getcwd())
>
> # Make sure the launch went ok
> if process:
> # Print some simple process info
> state = process.GetState ()
> print process
> if state == lldb.eStateStopped:
> # Get the first thread
> thread = process.GetThreadAtIndex (0)
> if thread:
> # Print some simple thread info
> print thread
> # Get the first frame
> frame = thread.GetFrameAtIndex (0)
> if frame:
> # Print some simple frame info
> print frame
> function = frame.GetFunction()
> # See if we have debug info (a function)
> if function:
> # We do have a function, print some info for the 
> function
> print function
> # Now get all instructions for this function and 
> print them
> insts = function.GetInstructions(target)
> disassemble_instructions (insts)
> else:
> # See if we have a symbol in the symbol table for 
> where we stopped
> symbol = frame.GetSymbol();
> if symbol:
> # We do have a symbol, print some info for the 
> symbol
> print symbol
>
>
> We set the async mode to false, so target.LaunchSimple() should not return
> until the process is stopped or exited. Note in your example it is
> returning with "state = launching", so this is what is failing. For some
> reason synchronous mode is not being obeyed.
>
> Greg
>
> On Feb 11, 2017, at 10:07 AM, Roman Popov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I'm testing example from https://lldb.llvm.org/python-reference.html
> (USING THE LLDB.PY MODULE IN PYTHON)  on Ubuntu 16.04
>
> For some reason it works only with LLDB 3.9, is it because LLDB 4.0/5.0
> are not stable yet?
>
> #5.0   -- Does not work
>
> deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial main
>
> # 3.9  -- Works
>
> deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-3.9 main
>
> # 4.0  -- Does not work
>
> deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-4.0 main
>
>
> >clang-5.0 -g test.cpp
>
> >./python_example.py
>
> Creating a target for './a.out'
> SBBreakpoint: id = 1, name = 'main', locations = 1
> SBProcess: pid = 0, state = launching, threads = 0, executable = a.out
>
> Thanks,
> Roman
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python example does not work with latest LLDBs

[Greg Clayton via lldb-dev]

I would be probably best to just step through it and see why it is incorrectly 
returning. We know it is broken. We should also add a test for this so we don't 
regress again.

Greg

> On Feb 13, 2017, at 10:19 AM, Roman Popov  wrote:
> 
> Yes Greg, this was my expectation that it should not return until stops on 
> break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9 to 
> make it work as expected.
> 
> Can I get some diagnostics? Any log files? 
> 
> 2017-02-13 20:11 GMT+03:00 Greg Clayton  >:
> The example code is:
> 
> #!/usr/bin/python
> 
> import lldb
> import os
> 
> def disassemble_instructions(insts):
> for i in insts:
> print i
> 
> # Set the path to the executable to debug
> exe = "./a.out"
> 
> # Create a new debugger instance
> debugger = lldb.SBDebugger.Create()
> 
> # When we step or continue, don't return from the function until the process 
> # stops. Otherwise we would have to handle the process events ourselves 
> which, while doable is
> #a little tricky.  We do this by setting the async mode to false.
> debugger.SetAsync (False)
> 
> # Create a target from a file and arch
> print "Creating a target for '%s'" % exe
> 
> target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
> 
> if target:
> # If the target is valid set a breakpoint at main
> main_bp = target.BreakpointCreateByName ("main", 
> target.GetExecutable().GetFilename());
> 
> print main_bp
> 
> # Launch the process. Since we specified synchronous mode, we won't return
> # from this function until we hit the breakpoint at main
> process = target.LaunchSimple (None, None, os.getcwd())
> 
> # Make sure the launch went ok
> if process:
> # Print some simple process info
> state = process.GetState ()
> print process
> if state == lldb.eStateStopped:
> # Get the first thread
> thread = process.GetThreadAtIndex (0)
> if thread:
> # Print some simple thread info
> print thread
> # Get the first frame
> frame = thread.GetFrameAtIndex (0)
> if frame:
> # Print some simple frame info
> print frame
> function = frame.GetFunction()
> # See if we have debug info (a function)
> if function:
> # We do have a function, print some info for the 
> function
> print function
> # Now get all instructions for this function and 
> print them
> insts = function.GetInstructions(target)
> disassemble_instructions (insts)
> else:
> # See if we have a symbol in the symbol table for 
> where we stopped
> symbol = frame.GetSymbol();
> if symbol:
> # We do have a symbol, print some info for the 
> symbol
> print symbol
> 
> We set the async mode to false, so target.LaunchSimple() should not return 
> until the process is stopped or exited. Note in your example it is returning 
> with "state = launching", so this is what is failing. For some reason 
> synchronous mode is not being obeyed.
> 
> Greg
> 
>> On Feb 11, 2017, at 10:07 AM, Roman Popov via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> I'm testing example from https://lldb.llvm.org/python-reference.html 
>>  (USING THE LLDB.PY MODULE IN 
>> PYTHON)  on Ubuntu 16.04
>> 
>> For some reason it works only with LLDB 3.9, is it because LLDB 4.0/5.0 are 
>> not stable yet?
>> 
>> #5.0   -- Does not work
>> deb http://apt.llvm.org/xenial/  
>> llvm-toolchain-xenial main
>> # 3.9  -- Works
>> deb http://apt.llvm.org/xenial/  
>> llvm-toolchain-xenial-3.9 main
>> # 4.0  -- Does not work
>> deb http://apt.llvm.org/xenial/  
>> llvm-toolchain-xenial-4.0 main
>> 
>> >clang-5.0 -g test.cpp
>> >./python_example.py
>> Creating a target for './a.out'
>> SBBreakpoint: id = 1, name = 'main', locations = 1
>> SBProcess: pid = 0, state = launching, threads = 0, executable = a.out
>> Thanks,
>> Roman
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python example does not work with latest LLDBs

[Roman Popov via lldb-dev]

Do you mean you were able to reproduce it? Because it is used to work on
trunk month ago, but since then I've switched from ubuntu 14.04 to fresh
16.04 and it no longer works for me.

2017-02-13 21:21 GMT+03:00 Greg Clayton :

> I would be probably best to just step through it and see why it is
> incorrectly returning. We know it is broken. We should also add a test for
> this so we don't regress again.
>
> Greg
>
> On Feb 13, 2017, at 10:19 AM, Roman Popov  wrote:
>
> Yes Greg, this was my expectation that it should not return until stops on
> break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9 to
> make it work as expected.
>
> Can I get some diagnostics? Any log files?
>
> 2017-02-13 20:11 GMT+03:00 Greg Clayton :
>
>> The example code is:
>>
>> #!/usr/bin/python
>>
>> import lldb
>> import os
>>
>> def disassemble_instructions(insts):
>> for i in insts:
>> print i
>> # Set the path to the executable to debug
>> exe = "./a.out"
>> # Create a new debugger instance
>> debugger = lldb.SBDebugger.Create()
>> # When we step or continue, don't return from the function until the process
>> # stops. Otherwise we would have to handle the process events ourselves 
>> which, while doable is
>> #a little tricky.  We do this by setting the async mode to false.
>> debugger.SetAsync (False)
>> # Create a target from a file and arch
>> print "Creating a target for '%s'" % exe
>>
>> target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
>>
>> if target:
>> # If the target is valid set a breakpoint at main
>> main_bp = target.BreakpointCreateByName ("main", 
>> target.GetExecutable().GetFilename());
>>
>> print main_bp
>>
>> # Launch the process. Since we specified synchronous mode, we won't 
>> return
>> # from this function until we hit the breakpoint at main
>> process = target.LaunchSimple (None, None, os.getcwd())
>>
>> # Make sure the launch went ok
>> if process:
>> # Print some simple process info
>> state = process.GetState ()
>> print process
>> if state == lldb.eStateStopped:
>> # Get the first thread
>> thread = process.GetThreadAtIndex (0)
>> if thread:
>> # Print some simple thread info
>> print thread
>> # Get the first frame
>> frame = thread.GetFrameAtIndex (0)
>> if frame:
>> # Print some simple frame info
>> print frame
>> function = frame.GetFunction()
>> # See if we have debug info (a function)
>> if function:
>> # We do have a function, print some info for the 
>> function
>> print function
>> # Now get all instructions for this function and 
>> print them
>> insts = function.GetInstructions(target)
>> disassemble_instructions (insts)
>> else:
>> # See if we have a symbol in the symbol table for 
>> where we stopped
>> symbol = frame.GetSymbol();
>> if symbol:
>> # We do have a symbol, print some info for the 
>> symbol
>> print symbol
>>
>>
>> We set the async mode to false, so target.LaunchSimple() should not
>> return until the process is stopped or exited. Note in your example it is
>> returning with "state = launching", so this is what is failing. For some
>> reason synchronous mode is not being obeyed.
>>
>> Greg
>>
>> On Feb 11, 2017, at 10:07 AM, Roman Popov via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I'm testing example from https://lldb.llvm.org/python-reference.html
>> (USING THE LLDB.PY MODULE IN PYTHON)  on Ubuntu 16.04
>>
>> For some reason it works only with LLDB 3.9, is it because LLDB 4.0/5.0
>> are not stable yet?
>>
>> #5.0   -- Does not work
>>
>> deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial main
>>
>> # 3.9  -- Works
>>
>> deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-3.9 main
>>
>> # 4.0  -- Does not work
>>
>> deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-4.0 main
>>
>>
>> >clang-5.0 -g test.cpp
>>
>> >./python_example.py
>>
>> Creating a target for './a.out'
>> SBBreakpoint: id = 1, name = 'main', locations = 1
>> SBProcess: pid = 0, state = launching, threads = 0, executable = a.out
>>
>> Thanks,
>> Roman
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

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 do what you want is to write a shared library, save it to 
"/tmp/liba.so" and then load it at runtime:

(lldb) process load /tmp/liba.so

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.

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:
- C++ lambda functions that don't capture anything can be cast to function 
pointer types and used as static callbacks.
- 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.
- Any type you declare that is prefixed with a '$' will persist beyond that 
expression and be available for future expressions.
- Any type returned as the result type of an expression will have its type 
available

Greg

> On Feb 13, 2017, at 6:00 AM, Roman Popov via lldb-dev 
>  wrote:
> 
> 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 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
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400531 a.out`main at a.cc:6
>3   void (* volatile hook)();
>4
>5   int main() {
> -> 6printf("before\n");
>7if(hook) hook();
>8printf("after\n");
>9   }
> (lldb) expr --top-level -- void HOOK() { (int)printf("in hook\n"); }
> (lldb) expr hook = &HOOK
> (void (*volatile)()) $0 = 0x77ff5030
> (lldb) c
> Process 22550 resuming
> before
> in hook
> after
> Process 22550 exited with status = 0 (0x)
> (lldb)
> 
> 
> On 13 February 2017 at 13:38, Roman Popov  > wrote:
> > 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 assign to
> > instrumentation_hook ?
> >
> >
> > 2017-02-13 16:33 GMT+03:00 Pavel Labath  > >:
> >>
> >> 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  >> > 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:
> >> >
> >> >
> >> > 

Re: [lldb-dev] Python example does not work with latest LLDBs

[Greg Clayton via lldb-dev]

Works for me with top of tree:

% PYTHONPATH=/tmp/lldb/build/Debug/LLDB.framework/Resources/Python ; ./foo.py )
Creating a target for './a.out'
SBBreakpoint: id = 1, name = 'main', module = a.out, locations = 1
SBProcess: pid = 62855, state = stopped, threads = 1, executable = a.out
thread #1: tid = 0x558f56, 0x00010226bf74 a.out`main(argc=1, 
argv=0x7fff5d994ec8) at main.cpp:15, queue = 'com.apple.main-thread', stop 
reason = breakpoint 1.1
frame #0: 0x00010226bf74 a.out`main(argc=1, argv=0x7fff5d994ec8) at 
main.cpp:15
SBFunction: id = 0x004b, name = main, type = main
a.out[0x10f60]: pushq  %rbp
a.out[0x10f61]: movq   %rsp, %rbp
a.out[0x10f64]: xorl   %eax, %eax
a.out[0x10f66]: movl   $0x0, -0x4(%rbp)
a.out[0x10f6d]: movl   %edi, -0x8(%rbp)
a.out[0x10f70]: movq   %rsi, -0x10(%rbp)
a.out[0x10f74]: popq   %rbp
a.out[0x10f75]: retq   

this is on a Mac though. Might be something specific to linux.

Greg

> On Feb 13, 2017, at 10:23 AM, Roman Popov  wrote:
> 
> Do you mean you were able to reproduce it? Because it is used to work on 
> trunk month ago, but since then I've switched from ubuntu 14.04 to fresh 
> 16.04 and it no longer works for me. 
> 
> 2017-02-13 21:21 GMT+03:00 Greg Clayton  >:
> I would be probably best to just step through it and see why it is 
> incorrectly returning. We know it is broken. We should also add a test for 
> this so we don't regress again.
> 
> Greg
> 
>> On Feb 13, 2017, at 10:19 AM, Roman Popov > > wrote:
>> 
>> Yes Greg, this was my expectation that it should not return until stops on 
>> break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9 to 
>> make it work as expected.
>> 
>> Can I get some diagnostics? Any log files? 
>> 
>> 2017-02-13 20:11 GMT+03:00 Greg Clayton > >:
>> The example code is:
>> 
>> #!/usr/bin/python
>> 
>> import lldb
>> import os
>> 
>> def disassemble_instructions(insts):
>> for i in insts:
>> print i
>> 
>> # Set the path to the executable to debug
>> exe = "./a.out"
>> 
>> # Create a new debugger instance
>> debugger = lldb.SBDebugger.Create()
>> 
>> # When we step or continue, don't return from the function until the process 
>> # stops. Otherwise we would have to handle the process events ourselves 
>> which, while doable is
>> #a little tricky.  We do this by setting the async mode to false.
>> debugger.SetAsync (False)
>> 
>> # Create a target from a file and arch
>> print "Creating a target for '%s'" % exe
>> 
>> target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
>> 
>> if target:
>> # If the target is valid set a breakpoint at main
>> main_bp = target.BreakpointCreateByName ("main", 
>> target.GetExecutable().GetFilename());
>> 
>> print main_bp
>> 
>> # Launch the process. Since we specified synchronous mode, we won't 
>> return
>> # from this function until we hit the breakpoint at main
>> process = target.LaunchSimple (None, None, os.getcwd())
>> 
>> # Make sure the launch went ok
>> if process:
>> # Print some simple process info
>> state = process.GetState ()
>> print process
>> if state == lldb.eStateStopped:
>> # Get the first thread
>> thread = process.GetThreadAtIndex (0)
>> if thread:
>> # Print some simple thread info
>> print thread
>> # Get the first frame
>> frame = thread.GetFrameAtIndex (0)
>> if frame:
>> # Print some simple frame info
>> print frame
>> function = frame.GetFunction()
>> # See if we have debug info (a function)
>> if function:
>> # We do have a function, print some info for the 
>> function
>> print function
>> # Now get all instructions for this function and 
>> print them
>> insts = function.GetInstructions(target)
>> disassemble_instructions (insts)
>> else:
>> # See if we have a symbol in the symbol table for 
>> where we stopped
>> symbol = frame.GetSymbol();
>> if symbol:
>> # We do have a symbol, print some info for the 
>> symbol
>> print symbol
>> 
>> We set the async mode to false, so target.LaunchSimple() should not return 
>> until the process is stopped or exited. Note in your example it is returning 
>> with "state = launching", so this is what is failing. For some reason 
>> synchronous mode is not being obeyed.
>> 
>> Greg
>> 
>>> On Feb 11, 2017, at 10:07 AM, Roman Popov via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> I'm testing example from ht

Re: [lldb-dev] Python example does not work with latest LLDBs

[Roman Popov via lldb-dev]

I've noticed that apt created some invalid symlinks, but fixing them did
not helped. I have a gut feeling that the problem is with prebuilt packages
from http://apt.llvm.org/ , not with lldb sources .
But we need someone else with Ubuntu 16.04 to confirm.

2017-02-13 22:15 GMT+03:00 Greg Clayton :

> Works for me with top of tree:
>
> % PYTHONPATH=/tmp/lldb/build/Debug/LLDB.framework/Resources/Python ;
> ./foo.py )
> Creating a target for './a.out'
> SBBreakpoint: id = 1, name = 'main', module = a.out, locations = 1
> SBProcess: pid = 62855, state = stopped, threads = 1, executable = a.out
> thread #1: tid = 0x558f56, 0x00010226bf74 a.out`main(argc=1,
> argv=0x7fff5d994ec8) at main.cpp:15, queue =
> 'com.apple.main-thread', stop reason = breakpoint 1.1
> frame #0: 0x00010226bf74 a.out`main(argc=1, argv=0x7fff5d994ec8)
> at main.cpp:15
> SBFunction: id = 0x004b, name = main, type = main
> a.out[0x10f60]: pushq  %rbp
> a.out[0x10f61]: movq   %rsp, %rbp
> a.out[0x10f64]: xorl   %eax, %eax
> a.out[0x10f66]: movl   $0x0, -0x4(%rbp)
> a.out[0x10f6d]: movl   %edi, -0x8(%rbp)
> a.out[0x10f70]: movq   %rsi, -0x10(%rbp)
> a.out[0x10f74]: popq   %rbp
> a.out[0x10f75]: retq
>
> this is on a Mac though. Might be something specific to linux.
>
> Greg
>
> On Feb 13, 2017, at 10:23 AM, Roman Popov  wrote:
>
> Do you mean you were able to reproduce it? Because it is used to work on
> trunk month ago, but since then I've switched from ubuntu 14.04 to fresh
> 16.04 and it no longer works for me.
>
> 2017-02-13 21:21 GMT+03:00 Greg Clayton :
>
>> I would be probably best to just step through it and see why it is
>> incorrectly returning. We know it is broken. We should also add a test for
>> this so we don't regress again.
>>
>> Greg
>>
>> On Feb 13, 2017, at 10:19 AM, Roman Popov  wrote:
>>
>> Yes Greg, this was my expectation that it should not return until stops
>> on break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9
>> to make it work as expected.
>>
>> Can I get some diagnostics? Any log files?
>>
>> 2017-02-13 20:11 GMT+03:00 Greg Clayton :
>>
>>> The example code is:
>>>
>>> #!/usr/bin/python
>>>
>>> import lldb
>>> import os
>>>
>>> def disassemble_instructions(insts):
>>> for i in insts:
>>> print i
>>> # Set the path to the executable to debug
>>> exe = "./a.out"
>>> # Create a new debugger instance
>>> debugger = lldb.SBDebugger.Create()
>>> # When we step or continue, don't return from the function until the process
>>> # stops. Otherwise we would have to handle the process events ourselves 
>>> which, while doable is
>>> #a little tricky.  We do this by setting the async mode to false.
>>> debugger.SetAsync (False)
>>> # Create a target from a file and arch
>>> print "Creating a target for '%s'" % exe
>>>
>>> target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
>>>
>>> if target:
>>> # If the target is valid set a breakpoint at main
>>> main_bp = target.BreakpointCreateByName ("main", 
>>> target.GetExecutable().GetFilename());
>>>
>>> print main_bp
>>>
>>> # Launch the process. Since we specified synchronous mode, we won't 
>>> return
>>> # from this function until we hit the breakpoint at main
>>> process = target.LaunchSimple (None, None, os.getcwd())
>>>
>>> # Make sure the launch went ok
>>> if process:
>>> # Print some simple process info
>>> state = process.GetState ()
>>> print process
>>> if state == lldb.eStateStopped:
>>> # Get the first thread
>>> thread = process.GetThreadAtIndex (0)
>>> if thread:
>>> # Print some simple thread info
>>> print thread
>>> # Get the first frame
>>> frame = thread.GetFrameAtIndex (0)
>>> if frame:
>>> # Print some simple frame info
>>> print frame
>>> function = frame.GetFunction()
>>> # See if we have debug info (a function)
>>> if function:
>>> # We do have a function, print some info for the 
>>> function
>>> print function
>>> # Now get all instructions for this function and 
>>> print them
>>> insts = function.GetInstructions(target)
>>> disassemble_instructions (insts)
>>> else:
>>> # See if we have a symbol in the symbol table for 
>>> where we stopped
>>> symbol = frame.GetSymbol();
>>> if symbol:
>>> # We do have a symbol, print some info for the 
>>> symbol
>>> print symbol
>>>
>>>
>>> We set the async mode to false, so target.LaunchSimple() should not
>>> return until the process is stopped or exited. Note in your 

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

[Roman Popov via lldb-dev]

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 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 do what you want is to write a shared library, save it
> to "/tmp/liba.so" and then load it at runtime:
>
> (lldb) process load /tmp/liba.so
>
> 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.
>
> 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:
> - C++ lambda functions that don't capture anything can be cast to function
> pointer types and used as static callbacks.
> - 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.
> - Any type you declare that is prefixed with a '$' will persist beyond
> that expression and be available for future expressions.
> - Any type returned as the result type of an expression will have its type
> available
>
> Greg
>
> On Feb 13, 2017, at 6:00 AM, Roman Popov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> 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 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
>> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
>> frame #0: 0x00400531 a.out`main at a.cc:6
>>3   void (* volatile hook)();
>>4
>>5   int main() {
>> -> 6printf("before\n");
>>7if(hook) hook();
>>8printf("after\n");
>>9   }
>> (lldb) expr --top-level -- void HOOK() { (int)printf("in hook\n"); }
>> (lldb) expr hook = &HOOK
>> (void (*volatile)()) $0 = 0x77ff5030
>> (lldb) c
>> Process 22550 resuming
>> before
>> in hook
>> after
>> Process 22550 exited with status = 0 (0x)
>> (lldb)
>>
>>
>> On 13 February 2017 at 13:38, Roman Popov  wrote:
>> > 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 assign to
>> > instrumentation_hook ?
>> >
>> >
>> > 2017-02-13 16:33 GMT+03:00 Pavel Labath :
>> >>
>> >> 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  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 p

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Reid Kleckner via lldb-dev]

These issues should be resolved by r295013 and r295014.

On Thu, Feb 9, 2017 at 1:55 PM, Hans Wennborg  wrote:

> I'm happy as long as it builds :-)
>
> On Wed, Feb 8, 2017 at 2:26 PM, Zachary Turner  wrote:
> > Should we do that now, as a way to fix this issue, or should we try to
> get
> > another fix in first so we have more time to think about using std
> > call_once?
> >
> > On Wed, Feb 8, 2017 at 2:19 PM Reid Kleckner  wrote:
> >>
> >> I think we can. MSVC's std::once_flag default constructor is constexpr
> >> now. It still generates dynamic initialization code if you use it as a
> >> static local, but MSVC defaults to using thread safe static
> initialization,
> >> so that isn't a problem unless you disable it, which we don't. We
> disable it
> >> in compiler-rt (/Zc:threadSafeInit-), but that doesn't use this code.
> >>
> >> On Wed, Feb 8, 2017 at 1:18 PM, Zachary Turner 
> wrote:
> >>>
> >>> Is this the right review?  https://reviews.llvm.org/D5922
> >>>
> >>> Being that this was over 2 years ago, I suspect it was when we were
> >>> supporting MSVC2012 and 2013.  Now that we're requiring MSVC2015, is
> it time
> >>> to reconsider? I don't see any links to an MS Connect issue, so I
> don't know
> >>> what the original bug was to know if it has been fixed.
> >>>
> >>>
> >>> On Wed, Feb 8, 2017 at 1:03 PM Reid Kleckner  wrote:
> 
>  It's a sad story. Read the comments and the review threads. It's
>  hilarious.
> 
>  On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev
>   wrote:
> >
> > Why doesn't llvm::call_once() just use std::call_once on Windows?
> >
> > On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg 
> > wrote:
> >>
> >> The Win64 lldb build seems broken (at 294367).
> >>
> >> I ran into this when trying to build the weekly snapshot
> >> (http://www.llvm.org/builds/) which includes LLDB these days.
> >>
> >> I suspect this might be related to Kamil's changes a few days ago. I
> >> see Pavel committed something to fix Darwin afterwards.
> >>
> >> Zach, do you know what's going on here? Do we have any buildbot
> >> coverage for this?
> >>
> >>Creating library lib\liblldb.lib and object lib\liblldb.exp
> >> lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
> >> external symbo
> >> l "void __cdecl llvm::sys::_mm_mfence(void)"
> >> (?_mm_mfence@sys@llvm@@YAXXZ) refer
> >> enced in function "void __cdecl llvm::call_once >>  >> 713e15728a6adc> >(struct llvm::once_flag &,class
> >>  >> 5728a6adc> &&)"
> >> (??$call_once@V@@$$V@ll
> >>
> >> vm@@YAXAEAUonce_flag@0@$$QEAV dc>@@@Z)
> >> bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
> >> LINK failed. with 1120
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >>
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

I've published a short report for the previous milestone, with goals for
the ongoing one.

   "The first patch-bulk upstreamed to LLDB"

http://blog.netbsd.org/tnf/entry/the_first_patch_bulk_upstreamed

The next one will turn to be more exciting as I plan to start with
implementation of accessors for machine context registers, followed up
with breakpoints.

On 23.01.2017 15:21, Kamil Rytarowski wrote:
> Hello,
> 
> For the reference in this thread, I've posted a blog entry on the NetBSD
> Foundation site with a summary of the interfaces we were discussing in
> this thread:
> 
> http://blog.netbsd.org/tnf/entry/summary_of_the_preliminary_lldb
> 
> This report covers the topics discussed in this E-mail thread.
> 
> I've got some thoughts on redefining current generic interface and
> making NativeThreadX optional, but let's see what will happen when we
> will get aboard appropriate support for still missing features
> (registers' accessors, breakpoints, watchpoints etc).
> 
> On 15.12.2016 17:21, Kamil Rytarowski wrote:
>> On 15.12.2016 16:08, Pavel Labath wrote:
>>> On 15 December 2016 at 14:14, Kamil Rytarowski  wrote:
 On 15.12.2016 14:14, Pavel Labath wrote:
>>>
>>> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
>>> add support for it in ptrace(2).
> This value is currently only used in logging code, so we can just
> remove it from the code base. However, it's a useful thing to have for
> the future, so it may be worth making sure the NetBSD kernel supports
> it.
>

 I was wondering whether waitid(2) or wait6(2) could be used there, as
 they return siginfo_t. If so, NetBSD does not need dedicated ptrace(2)
 entry.
>>>
>>> Note that there are two siginfo_t structures in action here. One is
>>> the siginfo_t the *inferior* gets as a result of some action (e.g.
>>> kill(), raise(), hitting an int3, etc.). The other is the siginfo_t
>>> corresponding to the SIGCHLD that the *debugger* gets when something
>>> interesting happens to the inferior. (On linux at least ), waitid(2)
>>> returns the second one. That one, however, generally does not contain
>>> any useful information apart from the process ID. PTRACE_GETSIGINFO
>>> returns the first one, and that one contains the interesting stuff
>>> (the signal the inferior recieved, and in case of a SIGTRAP, the
>>> information about the debug event is encoded there as well). This is
>>> usually very important information for the debugger.
>>>
>>> PTRACE_SETSIGINFO allows you to overwrite the signal that the inferior
>>> would receive. It can be used to inject "fake" signals into the
>>> inferior. That can be a useful feature from time to time, but
>>> currently we do not support that (on linux we support injecting a
>>> signal via an argument to PTRACE_CONTINUE, which is a weaker
>>> implementation of this call, as it can only inject a signal number,
>>> not the full siginfo_t struct). So you may want to implement this at
>>> some point, but on the grand scale of things, it's not something very
>>> important.
>>>
>>>
>>
>> I see, thank you for your explanation! It looks useful, but let it keep
>> for later.
>>
> 
> As per-blog entry, there is now an interface for it in NetBSD with
> PT_GETSIGINFO and PT_SETSIGINFO.
> 

>>>
>>> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
>>> equivalent to be implemented.
> Do you mean "implemented in lldb-server" or "implemented in the
> kernel"? Being notified when the inferior exec()s would definitely be
> good. Tracing thread creation and exit is a nice-to-have but low
> priority. The only reason we used it on linux is because that's the
> only way to auto-attach to new threads, but I think that for you that
> will happen automatically.
>

 I mean implemented in the kernel.

 Thread (lwp) creation and termination is currently detectable in FreeBSD
 with a special event, if this is useful in the NetBSD context -- like a
 user setting a break on this event explicitly -- I will add it to TODO
 list. On NetBSD there is no need to explicitly start tracing new
 threads, tracing is per process and it is composed of a bulk of threads
 (lwp). POSIX threads are a layer with extra features built upon LWP.
>>> BTW, are your debug registers per-process or per-thread? If they are
>>> per thread, then you will need to hook thread creation so you can
>>> inject the correct watchpoints and stuff, otherwise you will miss some
>>> hits. If this is handled by the kernel, then you are probably fine.
>>>
>>
>> Debug registers (watchpoints) are per-thread (lwp) and they are not
>> being inherited on thread's or process' forks. It's a valid use-case.
>>
>> I just checked FreeBSD and there is PTRACE_LWP:
>>
>> This event flag controls tracing of LWP kernel thread creation and
>> destruction. When this event is enabled, new LWPs will stop and report
>> an event with PL_FLAG_BORN