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

[Roman Popov via lldb-dev]

Yes, you're right. When I replaced unsigned with signed int it works
properly.

2017-02-10 19:46 GMT+03:00 Greg Clayton <gclayton at apple.com>:

>
> On Feb 10, 2017, at 12:55 AM, Roman Popov <ripopov at gmail.com> 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 = 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> > {
> ..}"
>
>
> 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>, 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 <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/00771501/attachment.html>