[llvm-bugs] [Bug 28150] New: [DebugInfo] Extend vtable debug info metadata to handle MS ABI

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28150

            Bug ID: 28150
           Summary: [DebugInfo] Extend vtable debug info metadata to
                    handle MS ABI
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rnk at google.com
                CC: amccarth at google.com, amjad.aboud at intel.com,
                    aprantl at apple.com, david.majnemer at gmail.com,
                    dblaikie at gmail.com, llvm-bugs at lists.llvm.org
            Blocks: 12283
    Classification: Unclassified

Currently DISubprograms have these vtable related fields:

- containingType: The parent class. Appears to be redundant with 'scope' for
virtual methods. We could repurpose this to point to the record that actually
contains the vfptr, since the vftable is very frequently not at offset 0 from
'this', and requires non-virtual and virtual adjustments.

- virtuality: Only has none, virtual, and pure_virtual. We might want to extend
this to include a notion of 'introducing', or we could encode that information
some other way.

- virtualIndex: Should be the vftable index obviously. For dwarf this is
relative to the address point, and we can make this the vftable index pretty
easily. CodeView only includes vftable offsets for introducing virtual methods,
so we could set this to a sentinel value (-1) to indicate that the virtual
method was not introduced in this class, and its offset can be found in the
DWARF describing the base class.

Another issue is that we can't assume that the frontend will provide complete
debug info type information for base classes unless we enable
-fstandalone-debug-info. This means we can't walk the entire class hierarchy in
order to generate this information. Each DICompositeType has to be
self-contained. This means we can't figure out which DICompositeType introduced
a virtual method by walking the class hierarchy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160616/9968035a/attachment.html>