<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>Actually, for GCC and LLVM, the location is an <u>index</u> into vtable, <u>not</u> an offset. We have a compiler abstraction that knows how to convert the DWARF DW_AT_vtable_elem_location to our internal representation of a location, because various compilers
 generate the DWARF differently and the contents of the vtable vary by target architecture. For example, on AIX and 64-bit Linux-Power, the vtable slot contains a pointer to a TOC entry, which in turn contains the pointer to the function followed by the TOC
 value for the function.</p></div></blockquote><div>Ah, I didn't compile a large enough example to see that it's an index rather than an offset. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>Here's a simple example for a program compiled with Clang on Linux-x86_64.</p>
<p>The DWARF for a virtual function is:</p>
<p><tt>0x000007aa:     DW_TAG_subprogram<br>
                  DW_AT_linkage_name    ("_ZN1A3gooEv")<br>
                  DW_AT_name    ("goo")<br>
                  DW_AT_decl_file       ("/.../tx_c++11_virtual.cxx")<br>
                  DW_AT_decl_line       (8)<br>
                  DW_AT_virtuality      (DW_VIRTUALITY_virtual)<br>
                  DW_AT_vtable_elem_location    (DW_OP_constu 0x1)<br>
                  DW_AT_declaration     (true)<br>
                  DW_AT_external        (true)<br>
                  DW_AT_containing_type (0x0000077d "A")</tt><br>
</p>
<p>And here is the internal location we created for that virtual function:</p>
<p><tt>{location {{indirect} {ldc 1} {ldc 8} {mul} {plus}}}</tt></p></div></blockquote><div>Now this is what the DWARF expression is supposed to look like. </div><div><br></div><div>It's odd to me that—in response to a bug report that complained that finding the vtable pointer of an object was too much ABI knowledge for the debuggers to handle—they implemented a buggy vtable_elem_location that required even more detailed ABI knowledge!</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>When that location is eventually used, the value of the vtable pointer is first pushed onto the location evaluation stack, and then the above location is resolved. The result is the location of the pointer to the function.</p>
<p>On AIX, for GCC, we build a location with an extra indirection through the TOC pointer to get to location of the function pointer in the TOC entry (which just happens to be at offset 0):<br>
</p>
<p><tt>{location {{indirect} {ldc 1} {ldc 8} {mul} {plus} {indirect}}}</tt><br>
</p>
<p>So, in practice, handling DW_AT_vtable_elem_location is both highly compiler and platform dependent. I guess that's what you should expect with a permissive standard.</p></div></blockquote><div>But the standard isn't even permissive here! It's very clear (from DWARF 2 on) that it should be an expression that evaluates to the location of the vtable entry.</div><div><br></div><div>If the implementers had wanted to take advantage of a permissive standard, they'd have been better advised to use a constant form for the vtable element index. Such a usage could have easily been standardized after the fact. (And it would have been more space efficient.)</div><div><br></div><div>-cary</div><div><br></div></div></div>