[Bug debug/56376] New: gdb needs a way to associate a vtable symbol with a class type

[tromey at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56376

             Bug #: 56376
           Summary: gdb needs a way to associate a vtable symbol with a
                    class type
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tromey@gcc.gnu.org


gdb needs a way to associate a vtable symbol with a type.
Some background:

gdb has a feature ("set print object on") where it tries to
examine an object's vtable to find the object's real, dynamic
type.

It examines the vtable pointer, then finds the vtable's ELF symbol,
demangles the symbol name, and finally (ewwww....) strips off
"vtable for" from the demangled name and looks up the result
as a type name in the DWARF.

However, this approach doesn't work in some cases.  For example,
it fails if the type is defined locally to a function.
See http://sourceware.org/bugzilla/show_bug.cgi?id=14235

Here (at least in the example in comment #10), there is no way to
associate a vtable with the appropriate type.

To solve these problems it would be nice if, at the very least for
the defined-in-a-function case, GCC emitted some DWARF that would
associate a vtable with a type.  I think for this to really work
it would have to do this for all vtables thus defined -- e.g., so that
inspecting an object that is partially constructed would also DTRT.

One approach would be to emit it as an artificial variable.
For gdb it would be more convenient if it were top-level, but anywhere
sane would work.  Like:

DW_TAG_variable
   DW_AT_linkage_name _Zblahblah
   DW_AT_artificial
   DW_AT_containing_type <class die ref>

But perhaps this is too magical and a new DW_TAG_GNU_vtable would
be better.