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,
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, e
> 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
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 s
It just says where it is inside the class itself, not what the value of the
vtable pointer is:
0x6628: TAG_structure_type [112] *
AT_containing_type( {0x6628} )
AT_name( "base_type" )
AT_byte_size( 0x08 )
AT_d
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 dynam
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 spec
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
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 nam
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( "/
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 C
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 Clayto
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
> wrote:
>
> Hello,
> I'm observing very strange LLDB behavior: it does not always shows a correct
> dynamic type when
13 matches
Mail list logo
