<div dir="ltr"><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">I've written a three-part proposal to address these issues:</span></div><div><ul><li><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">The first part,<span class="gmail-Apple-converted-space"> </span></span><a href="https://dwarfstd.org/issues/250506.1.html" style="font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif">250506.1</a><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">, proposes a standard mechanism for locating the virtual function table (vtable) given an object of a polymorphic class.</span></li><li><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">The second part,<span class="gmail-Apple-converted-space"> </span></span><a href="https://dwarfstd.org/issues/250506.2.html" style="font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif">250506.2</a><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">, proposes a standard mechanism for identifying the most-derived class of an object, given its vtable location, in order to support downcasting of pointers while debugging. </span></li><li><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">The third part,<span class="gmail-Apple-converted-space"> </span></span><a href="https://dwarfstd.org/issues/250506.3.html" style="font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif">250506.3</a><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">, proposes a fix to the </span><code>DW_AT_vtable_elem_location</code><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium"><span class="gmail-Apple-converted-space"> </span>attribute, which appears to be incorrectly implemented in compilers today.</span></li></ul><div><font color="#000000" face="Nunito Sans, Lucida Grande, Lucida Sans Unicode, Lucida Sans, Lucida, sans-serif" size="3"><span style="caret-color: rgb(0, 0, 0);">-cary</span></font></div></div></div><div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, May 2, 2025 at 1:31 PM Todd Allen via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>FWIW, when we at Concurrent were in the compiler business, our C++ compilers generated two vendor-defined attributes, both hanging off the DW_TAG_{structure,class}_type. Here are a couple with some sample locations:<br>
</div>
<blockquote>
<div><font face="monospace">DW_AT_vtable_location [DW_OP_plus_uconst 0; DW_OP_deref]<br>
</font></div>
<div><font face="monospace">DW_AT_type_vtable_location [DW_OP_addr 0x12345678]</font></div>
</blockquote>
<div>The first was a description of how to obtain the address of the vtable tag from an object.</div>
<div>The second was a description of the address of the vtable tag from just the type.</div>
<div><br>
</div>
<div>As we characterized them internally, they didn't have to be the address of the vtable proper. They just had to be something that could be compared as a positive identification of the actual type. I believe they always were the
actual vtable addresses, though. Because why not?<br>
</div>
<div><br>
</div>
<div>We do still have logic in our debugger to use them, too. In addition to the mangling-based approaches.<br>
</div>
<div><br>
</div>
<div>It does require walking the whole DWARF tree to find them.</div>
<div><br>
</div>
<div>Todd<br>
</div>
<div><br>
</div>
<div>On 4/25/25 09:49, Jeremy Morse via Dwarf-discuss wrote:<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Hi all,<br>
<br>
The LLVM discussion linked [0] happens to be us Sony folks, and it's supporting the use-case Kyle described of automatic downcasting, i.e. identifying the most-derived-class of an object from its vtable pointer. Having to demangle the symbol table is a real
pain (Tom, CC'd knows more) especially with things like anonymous namespaces.<br>
<br>
Right now the approach is to have a top-level nameless global variable with the location set to the vtable address, and a DW_AT_specification linking into the class definition:<br>
<br>
<font face="monospace">0x00000082: DW_TAG_variable</font><br>
<font face="monospace"> DW_AT_specification (0x000000b6 "_vtable$")</font><br>
<font face="monospace"> DW_AT_alignment (8)</font><br>
<font face="monospace"> DW_AT_location (DW_OP_addrx 0x1)</font><br>
<br>
<font face="arial, sans-serif">[Then deeper into the DIE tree,]</font>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">0x0000008b: DW_TAG_structure_type<br>
DW_AT_containing_type (0x00000034 "CBase")<br>
DW_AT_calling_convention (DW_CC_pass_by_reference)<br>
DW_AT_name ("CDerived")<br>
DW_AT_decl_file ("vtables.cpp")<br>
DW_AT_decl_line (6)</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace"> [...]<br>
<br>
0x000000b6: DW_TAG_variable<br>
DW_AT_name ("_vtable$")<br>
DW_AT_type (0x00000081 "void *")<br>
DW_AT_external (true)<br>
DW_AT_declaration (true)<br>
DW_AT_artificial (true)<br>
DW_AT_accessibility (DW_ACCESS_private)</font><br>
<br>
This works well enough for our own debugger use-cases; I agree with Cary that it's hacky to rely on the name of a variable to signify important information like this and an officially blessed way could help.</div>
<div><br>
</div>
<div>I've no opinion on the <span style="font-family:monospace">DW_AT_vtable_elem_location
</span><font face="arial, sans-serif">behaviours, although we can consider it a separate issue.</font><br>
<br>
[0] <a href="https://github.com/llvm/llvm-project/pull/130255" target="_blank">
https://github.com/llvm/llvm-project/pull/130255</a></div>
<div><br>
</div>
<div>--</div>
<div>Thanks,</div>
<div>Jeremy</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset></fieldset> </blockquote>
<p><br>
</p>
</div>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote></div></div>