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

[Greg Clayton via lldb-dev]

Roman,

Thanks for verifying. I am trying to see how far this goes.

It would be interesting to look at the GCC DWARF for this. If you can attach a copy of the binary, I would like to take a look to see if the DWARF itself has any offending type info where it sometimes has the 'u' and other times doesn't. We know and understand that clang does this, but we don't know if GCC does this as well and it would be good to know.

Greg

> On Feb 10, 2017, at 12:24 PM, Roman Popov <ripopov at gmail.com> wrote:
> 
> 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 <mailto:gclayton at apple.com>>:
> 
>> On Feb 10, 2017, at 12:55 AM, Roman Popov <ripopov at gmail.com <mailto: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 <mailto:gclayton at apple.com>>:
>> 
>> > On Feb 6, 2017, at 5:58 PM, Roman Popov <ripopov at gmail.com <mailto: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/33583bb9/attachment-0001.html>