Doesn't the DWARF have a record for the VTable itself? I know PDB does, you can look up the class name through the VTable debug info record rather than trying to demangle the name.
On Mon, Feb 6, 2017 at 2:21 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Yeah, when doing dynamic type resolution, we look at the first pointer > inside the pointer and see if it resolves to a virtual table symbol. If it > does, we extract the class name from the demangled symbol name and try to > look up. GDB does the same thing. All debuggers do AFAIK. > > If the DWARF specified the vtable address in the DWARF on the class > definition this would help, but without that the only thing we can really > do is to try and figure out the class and look it up by name. Also, even if > this is added to future DWARF, it doesn’t fix the problem that we have many > compilers that don’t have the info so we would still need to do what we do. > > If anyone has any better ideas I am all ears? > > Greg > > On Feb 6, 2017, at 11:48 AM, Robinson, Paul <paul.robin...@sony.com> > wrote: > > 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 > <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: > > > 0x000065da: TAG_structure_type [112] * > AT_containing_type( {0x0000000000006628} ) > AT_name( "derived0<int, int, 1024>" ) > 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<int, int, 1024u>”. 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, > int, 1024u>” and we fail since the DWARF has it as "derived0<int, int, > 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 <ripo...@gmail.com> 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 <gclay...@apple.com>: > 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 <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; > } > > > 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<int, int> *) $2 = 0x0000000000614c40 > > (lldb) expression -d no-run -- bptr0 > *(base_type *) $3 = 0x0000000000614c20* > > > Can someone explain me why for bptr0 I dont get a derived0<int, int, > 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
