[lldb-dev] Why SBValue::Cast is deprecated and how to replace it with expression?
Hello, SBValue::Cast marked as deprecated in LLDB headers: // Deprecated - use the expression evaluator to perform type casting lldb::SBValue Cast(lldb::SBType type); But I can't understand how to replace it with expression evaluation. Suppose I have: auto casted_val = my_value.Cast(my_type); What would be equivalent expression, taking into account that both value and type can be out of current scope? Same question on stackoverflow: http://stackoverflow.com/questions/41928915/lldb-api-why-sbvaluecast-is-deprecated-and-how-to-replace-it-with-createvalue Thanks in advance for help, -Roman ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RTTI does not work stable in LLDB.
Hello,
I'm observing very strange LLDB behavior: it does not always shows a
correct dynamic type when I ask for.
Originally I was working with LLDB 3.9, but it looks like trunk version
behaves the same strange way.
I was able to capture this behavior in a small code snippet:
#include
#include
using namespace std;
struct base_type { virtual ~base_type(){} };
template
struct derived0 : base_type {};
template
struct derived1 : base_type {};
int main(int argc, char ** argv) {
base_type * bptr0 = new derived0();
base_type * bptr1 = new derived1();
cout << typeid(*bptr0).name() << endl;
cout << typeid(*bptr1).name() << endl;
return 0;
}
lldb --version
lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
293398)
clang revision 293398
llvm revision 293398
Testing in LLDB:
(lldb) break set --file main.cpp --line 22
(lldb) expression -d no-run -- bptr1
(derived1 *) $2 = 0x00614c40
(lldb) expression -d no-run -- bptr0
*(base_type *) $3 = 0x00614c20*
Can someone explain me why for bptr0 I dont get a derived0
* as I expected?
Thanks,
Roman
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RTTI does not work stable in LLDB.
Yes, that was my thought.
FYI, checked in GDB: it's working correctly on this testcase showing
correct dynamic type in both cases.
2017-02-06 9:48 GMT-08:00 Greg Clayton :
> You have found a bug. It should be reporting this correctly but it isn’t.
> I verified it fails on MacOSX.
>
> Greg Clayton
>
> On Feb 5, 2017, at 1:19 PM, Roman Popov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello,
> I'm observing very strange LLDB behavior: it does not always shows a
> correct dynamic type when I ask for.
>
> Originally I was working with LLDB 3.9, but it looks like trunk version
> behaves the same strange way.
>
> I was able to capture this behavior in a small code snippet:
>
> #include
> #include
>
> using namespace std;
>
> struct base_type { virtual ~base_type(){} };
>
> template
> struct derived0 : base_type {};
>
> template
> struct derived1 : base_type {};
>
> int main(int argc, char ** argv) {
>
> base_type * bptr0 = new derived0();
> base_type * bptr1 = new derived1();
>
> cout << typeid(*bptr0).name() << endl;
> cout << typeid(*bptr1).name() << endl;
>
> return 0;
> }
>
>
> lldb --version
> lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
> 293398)
> clang revision 293398
> llvm revision 293398
>
>
> Testing in LLDB:
> (lldb) break set --file main.cpp --line 22
>
> (lldb) expression -d no-run -- bptr1
> (derived1 *) $2 = 0x00614c40
>
> (lldb) expression -d no-run -- bptr0
> *(base_type *) $3 = 0x00614c20*
>
>
> Can someone explain me why for bptr0 I dont get a derived0 1024> * as I expected?
>
>
> 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] RTTI does not work stable in LLDB.
I confirm GCC4.8 puts derived0 into DWARF and LLDB
correctly identifies dynamic type.
2017-02-06 11:48 GMT-08:00 Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org>:
> So is LLDB expecting the name in the DWARF info to match the demangled
> name of the vtable pointer? The DWARF spec does not really specify what
> the name of a template instantiation should be, and in particular does not
> *want* to specify whether it matches any given demangler's opinion of the
> name.
>
> --paulr
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of *Greg
> Clayton via lldb-dev
> *Sent:* Monday, February 06, 2017 11:08 AM
> *To:* Greg Clayton
> *Cc:* lldb-dev@lists.llvm.org
> *Subject:* Re: [lldb-dev] RTTI does not work stable in LLDB.
>
>
>
> So I found the problem. This is a compiler bug. The DWARF for this type
> looks like:
>
>
>
> 0x65da: TAG_structure_type [112] *
> AT_containing_type( {0x6628} )
> AT_name( "derived0" )
> AT_byte_size( 0x08 )
> AT_decl_file( "/private/tmp/main.cpp" )
> AT_decl_line( 9 )
>
>
>
> But all of the type info in the symbol table has has the type named as
> "derived0”. Note the extra “u” that follows 1024. This
> stops LLDB from being able to lookup the type correctly so we can show the
> dynamic type. In LLDB we check the first pointer inside of a class to see
> if it is a symbol whose name is “vtable for TYPENAME”. If it is, we
> lookup the type “TYPENAME” to find it. In this case we try to lookup
> "derived0 int, 1024u>” and we fail since the DWARF has it as "derived0 1024>”.
>
>
>
> I have filed a radar on the compiler here at Apple for the fix.
>
>
>
> Greg
>
>
>
>
>
> On Feb 6, 2017, at 10:22 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> I am looking at this now. I will let you know what I find.
>
>
>
> Greg
>
>
>
> On Feb 6, 2017, at 10:00 AM, Roman Popov wrote:
>
>
>
> Yes, that was my thought.
>
>
>
> FYI, checked in GDB: it's working correctly on this testcase showing
> correct dynamic type in both cases.
>
>
>
> 2017-02-06 9:48 GMT-08:00 Greg Clayton :
>
> You have found a bug. It should be reporting this correctly but it isn’t.
> I verified it fails on MacOSX.
>
>
>
> Greg Clayton
>
>
>
> On Feb 5, 2017, at 1:19 PM, Roman Popov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> Hello,
>
> I'm observing very strange LLDB behavior: it does not always shows a
> correct dynamic type when I ask for.
>
>
>
> Originally I was working with LLDB 3.9, but it looks like trunk version
> behaves the same strange way.
>
>
>
> I was able to capture this behavior in a small code snippet:
>
>
>
> #include
>
> #include
>
>
>
> using namespace std;
>
>
>
> struct base_type { virtual ~base_type(){} };
>
>
>
> template
>
> struct derived0 : base_type {};
>
>
>
> template
>
> struct derived1 : base_type {};
>
>
>
> int main(int argc, char ** argv) {
>
>
>
> base_type * bptr0 = new derived0();
>
> base_type * bptr1 = new derived1();
>
>
>
> cout << typeid(*bptr0).name() << endl;
>
> cout << typeid(*bptr1).name() << endl;
>
>
>
> return 0;
>
> }
>
>
>
>
>
> lldb --version
>
> lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
> 293398)
>
> clang revision 293398
>
> llvm revision 293398
>
>
>
>
>
> Testing in LLDB:
>
> (lldb) break set --file main.cpp --line 22
>
>
>
> (lldb) expression -d no-run -- bptr1
>
> (derived1 *) $2 = 0x00614c40
>
>
>
> (lldb) expression -d no-run -- bptr0
>
> *(base_type *) $3 = 0x00614c20*
>
>
>
>
>
> Can someone explain me why for bptr0 I dont get a derived0 1024> * as I expected?
>
>
>
>
>
> 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
>
>
>
> ___
> 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] RTTI does not work stable in LLDB.
Hello, I just found out that sometimes I don't get correct dynamic type in LLDB even if I compile with g++. How can I get typeinfo/vtable dump from LLDB to check if it is still the same name matching issue? 2017-02-06 17:04 GMT-08:00 Robinson, Paul via lldb-dev < lldb-dev@lists.llvm.org>: > Yes, I do get that it was just unfortunate timing. Sorry for failing at > being light-hearted. > > > > I suspect the compiler can be persuaded to emit a name consistent with the > demangling of the vtable name. Despite being the way-things-have-worked > for a long time, it still seems moderately fragile, especially in the face > of various compiler-list debates about what the name actually should > contain. > > --paulr > > > > *From:* Greg Clayton [mailto:gclay...@apple.com] > *Sent:* Monday, February 06, 2017 4:38 PM > *To:* Robinson, Paul > *Cc:* Zachary Turner; LLDB Dev (lldb-dev@lists.llvm.org) > *Subject:* Re: [lldb-dev] RTTI does not work stable in LLDB. > > > > > > On Feb 6, 2017, at 3:38 PM, Robinson, Paul wrote: > > > > It's not practical for the DWARF to try to identify the actual address of > the vtable; that address might not be available. > > it seems like we could hang onto the linkage_name of the vtable though, > somewhere, so you wouldn't be relying on the demangler you have available > at runtime to produce the same string that the compiler did at compile > time. The symbolic name of the vtable should be unambiguous (one hopes!) > but not depend on the existence of the vtable in any particular place. > > Doesn't solve the problem for today's compilers, granted. > > --paulr > > > > P.S. It would be helpful to have these things come up *before* the next > rev of the spec is frozen. Just sayin'. J > > > > > > We had just identified this today and realized it was a problem so we had > no idea there was a problem until today. Debuggers have been doing this > pretty reliably for the past 15 years, so it was never anything we actually > needed extra support for since it was so easy to do. > > > > Greg > > > > > > > > ___ > 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] RTTI does not work stable in LLDB.
Thanks Greg,
So here is another case when LLDB fails to resolve dynamic type. Compiled
with G++5.4 on Ubuntu 16.04.
Here I want to get dynamic type for some variable apb_memories
(lldb) expr -d no-run -- apb_memories
(sc_core::sc_object *) $3 = 0x00cb6aa8
(lldb) memory read --format address apb_memories
0x00cb6aa8: 0x004e33f8 test_design`vtable for
demo::apb_memory, sc_dt::sc_uint<32>, 1024u> + 24
...
(lldb) image lookup -t "demo::apb_memory,
sc_dt::sc_uint<32>, 1024u>"
(lldb) image lookup -t "apb_memory, sc_dt::sc_uint<32>,
1024u>"
Best match found in ...
id = {0x0002cc4b}, name = "apb_memory,
sc_dt::sc_uint<32>, 1024u>", qualified = "demo::apb_memory,
sc_dt::sc_uint<32>, 1024>", byte-size = 27384, decl = apb_memory.h:15,
compiler_type = "class apb_memory : public sc_core::sc_module, public
demo::clk_rstn_sif, public demo::apb_if,
sc_dt::sc_uint<32> > {
..}"
Looks like in that case the problem is with namespace specifier. G++ did
not put it into debug info.
I hope it will be fixed soon, at least for Clang+LLDB combo. Probably you
need to write a unit-test that will check typeinfo against debug info for
various scenarios.
2017-02-09 4:04 GMT+03:00 Greg Clayton :
>
> > On Feb 6, 2017, at 5:58 PM, Roman Popov wrote:
> >
> > Hello,
> > I just found out that sometimes I don't get correct dynamic type in LLDB
> even if I compile with g++. How can I get typeinfo/vtable dump from LLDB
> to check if it is still the same name matching issue?
>
>
> Stop where dynamic typing fails, and take the pointer that is failing to
> be properly typed and do:
>
> (lldb) memory read --format address my_ptr
>
> Then look at the first entry that is in the output and it should be
> "vtable for " and take all the characters that follow this and are before
> the " + XXX" and check to see if LLDB knows about this type.
>
> If we use your previous source:
>
> #include
> #include
>
> using namespace std;
>
> struct base_type { virtual ~base_type(){} };
>
> template
> struct derived0 : base_type {};
>
> template
> struct derived1 : base_type {};
>
> int main(int argc, char ** argv) {
>
> base_type * bptr0 = new derived0();
> base_type * bptr1 = new derived1();
>
> cout << typeid(*bptr0).name() << endl;
> cout << typeid(*bptr1).name() << endl;
>
> return 0;
> }
>
>
>
>
> If we compile this into "a.out":
>
> % lldb a.out
> (lldb) b /return 0/
> (lldb) r
> (lldb) memory read --format address bptr0
> 0x1001002f0: 0x00012120 vtable for derived0 + 16
>
>
> We now take all text past the "vtable for " and before the " + 16" and
> lookup the type by name:
>
> (lldb) image lookup -t "derived0"
>
> Note this doesn't work, but if we remove the 'u' from 1024 it does work:
>
> (lldb) image lookup -t "derived0"
> Best match found in /tmp/a.out:
> id = {0x65da}, name = "derived0", byte-size = 8, decl
> = main.cpp:9, compiler_type = "class derived0 : public base_type {
> }"
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RTTI does not work stable in LLDB.
Yes, you're right. When I replaced unsigned with signed int it works
properly.
2017-02-10 19:46 GMT+03:00 Greg Clayton :
>
> On Feb 10, 2017, at 12:55 AM, Roman Popov wrote:
>
> Thanks Greg,
>
> So here is another case when LLDB fails to resolve dynamic type. Compiled
> with G++5.4 on Ubuntu 16.04.
>
> Here I want to get dynamic type for some variable apb_memories
>
> (lldb) expr -d no-run -- apb_memories
> (sc_core::sc_object *) $3 = 0x00cb6aa8
>
>
> (lldb) memory read --format address apb_memories
> 0x00cb6aa8: 0x004e33f8 test_design`vtable for
> demo::apb_memory, sc_dt::sc_uint<32>, 1024u> + 24
> ...
>
> (lldb) image lookup -t "demo::apb_memory,
> sc_dt::sc_uint<32>, 1024u>"
>
> (lldb) image lookup -t "apb_memory,
> sc_dt::sc_uint<32>, 1024u>"
> Best match found in ...
> id = {0x0002cc4b}, name = "apb_memory,
> sc_dt::sc_uint<32>, 1024u>", qualified = "demo::apb_memory,
> sc_dt::sc_uint<32>, 1024>", byte-size = 27384, decl = apb_memory.h:15,
> compiler_type = "class apb_memory : public sc_core::sc_module, public
> demo::clk_rstn_sif, public demo::apb_if,
> sc_dt::sc_uint<32> > {
> ..}"
>
>
> If you look at the "qualified" name in the type info you dumped, we see a
> 'u' mismatch on the last 1024:
>
> qualified = "demo::apb_memory, sc_dt::sc_uint<32>,
> 1024>"
>
> Note the missing 'u'. In the case of GCC and everything linux, we manually
> create the accelerator tables by indexing the DWARF manually. I am guessing
> that since the "qualified" name is wrong, this is what is keeping us from
> finding it. So this is the same problem, though this one is an LLDB bug if
> the qualified name is dropping the 'u'. We are presumably using the same
> code path that clang uses (which is causing this bug) to generate the
> qualified name.
>
> Greg
>
>
>
>
> Looks like in that case the problem is with namespace specifier. G++ did
> not put it into debug info.
>
> I hope it will be fixed soon, at least for Clang+LLDB combo. Probably you
> need to write a unit-test that will check typeinfo against debug info for
> various scenarios.
>
>
>
> 2017-02-09 4:04 GMT+03:00 Greg Clayton :
>
>>
>> > On Feb 6, 2017, at 5:58 PM, Roman Popov wrote:
>> >
>> > Hello,
>> > I just found out that sometimes I don't get correct dynamic type in
>> LLDB even if I compile with g++. How can I get typeinfo/vtable dump from
>> LLDB to check if it is still the same name matching issue?
>>
>>
>> Stop where dynamic typing fails, and take the pointer that is failing to
>> be properly typed and do:
>>
>> (lldb) memory read --format address my_ptr
>>
>> Then look at the first entry that is in the output and it should be
>> "vtable for " and take all the characters that follow this and are before
>> the " + XXX" and check to see if LLDB knows about this type.
>>
>> If we use your previous source:
>>
>> #include
>> #include
>>
>> using namespace std;
>>
>> struct base_type { virtual ~base_type(){} };
>>
>> template
>> struct derived0 : base_type {};
>>
>> template
>> struct derived1 : base_type {};
>>
>> int main(int argc, char ** argv) {
>>
>> base_type * bptr0 = new derived0();
>> base_type * bptr1 = new derived1();
>>
>> cout << typeid(*bptr0).name() << endl;
>> cout << typeid(*bptr1).name() << endl;
>>
>> return 0;
>> }
>>
>>
>>
>>
>> If we compile this into "a.out":
>>
>> % lldb a.out
>> (lldb) b /return 0/
>> (lldb) r
>> (lldb) memory read --format address bptr0
>> 0x1001002f0: 0x00012120 vtable for derived0 + 16
>>
>>
>> We now take all text past the "vtable for " and before the " + 16" and
>> lookup the type by name:
>>
>> (lldb) image lookup -t "derived0"
>>
>> Note this doesn't work, but if we remove the 'u' from 1024 it does work:
>>
>> (lldb) image lookup -t "derived0"
>> Best match found in /tmp/a.out:
>> id = {0x65da}, name = "derived0", byte-size = 8, decl
>> = main.cpp:9, compiler_type = "class derived0 : public base_type {
>> }"
>>
>>
>>
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Python example does not work with latest LLDBs
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
Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?
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
Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?
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?
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 wr
Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?
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] Python example does not work with latest LLDBs
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
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] Python example does not work with latest LLDBs
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?
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 inser
