[lldb-dev] RTTI does not work stable in LLDB.

[Roman Popov via lldb-dev]

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 = 0x0000000000cb6aa8


(lldb) memory read --format address apb_memories
0x00cb6aa8: 0x00000000004e33f8 test_design`vtable for
demo::apb_memory<sc_dt::sc_uint<32>, sc_dt::sc_uint<32>, 1024u> + 24
...

(lldb) image lookup -t "demo::apb_memory<sc_dt::sc_uint<32>,
sc_dt::sc_uint<32>, 1024u>"

(lldb) image lookup -t "apb_memory<sc_dt::sc_uint<32>, sc_dt::sc_uint<32>,
1024u>"
Best match found in ...
id = {0x0002cc4b}, name = "apb_memory<sc_dt::sc_uint<32>,
sc_dt::sc_uint<32>, 1024u>", qualified = "demo::apb_memory<sc_dt::sc_uint<32>,
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>,
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 <gclayton at apple.com>:

>
> > On Feb 6, 2017, at 5:58 PM, Roman Popov <ripopov at gmail.com> 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 <iostream>
> #include <typeinfo>
>
> using namespace std;
>
> struct base_type {  virtual ~base_type(){} };
>
> template <class T1, class T2, unsigned SIZE>
> struct derived0 : base_type {};
>
> template <class T1, class T2>
> struct derived1 : base_type {};
>
> int main(int argc, char ** argv) {
>
>     base_type * bptr0 = new derived0<int, int, 1024>();
>     base_type * bptr1 = new derived1<int, int >();
>
>     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: 0x0000000100002120 vtable for derived0<int, int, 1024u> + 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<int, int, 1024u>"
>
> Note this doesn't work, but if we remove the 'u' from 1024 it does work:
>
> (lldb) image lookup -t "derived0<int, int, 1024>"
> Best match found in /tmp/a.out:
> id = {0x000065da}, name = "derived0<int, int, 1024>", byte-size = 8, decl
> = main.cpp:9, compiler_type = "class derived0 : public base_type {
> }"
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170210/292aea65/attachment-0001.html>