In 250506.2, the use of a rnglist is throwing me. I would expect the lifetime of a vtable to be the whole program. Or did you envision the rnglist to be the range of data/rodata addresses of the vtable object? 2.17 clarifies that they're code addresses (i.e. text), though.
We did have a discussion sometime in the last year about describing data/rodata address ranges, but that was in .debug_aranges (RIP). And, IIRC, no actual compiler was generating data/rodata address there either. On 5/6/25 19:19, Cary Coutant wrote: I've written a three-part proposal to address these issues: * The first part, 250506.1<https://dwarfstd.org/issues/250506.1.html>, proposes a standard mechanism for locating the virtual function table (vtable) given an object of a polymorphic class. * The second part, 250506.2<https://dwarfstd.org/issues/250506.2.html>, 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. * The third part, 250506.3<https://dwarfstd.org/issues/250506.3.html>, proposes a fix to the DW_AT_vtable_elem_location attribute, which appears to be incorrectly implemented in compilers today. -cary On Fri, May 2, 2025 at 1:31 PM Todd Allen via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org<mailto:dwarf-discuss@lists.dwarfstd.org>> wrote: 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: DW_AT_vtable_location [DW_OP_plus_uconst 0; DW_OP_deref] DW_AT_type_vtable_location [DW_OP_addr 0x12345678] The first was a description of how to obtain the address of the vtable tag from an object. The second was a description of the address of the vtable tag from just the type. 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? We do still have logic in our debugger to use them, too. In addition to the mangling-based approaches. It does require walking the whole DWARF tree to find them. Todd On 4/25/25 09:49, Jeremy Morse via Dwarf-discuss wrote: Hi all, 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. 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: 0x00000082: DW_TAG_variable DW_AT_specification (0x000000b6 "_vtable$") DW_AT_alignment (8) DW_AT_location (DW_OP_addrx 0x1) [Then deeper into the DIE tree,] 0x0000008b: DW_TAG_structure_type DW_AT_containing_type (0x00000034 "CBase") DW_AT_calling_convention (DW_CC_pass_by_reference) DW_AT_name ("CDerived") DW_AT_decl_file ("vtables.cpp") DW_AT_decl_line (6) [...] 0x000000b6: DW_TAG_variable DW_AT_name ("_vtable$") DW_AT_type (0x00000081 "void *") DW_AT_external (true) DW_AT_declaration (true) DW_AT_artificial (true) DW_AT_accessibility (DW_ACCESS_private) 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. I've no opinion on the DW_AT_vtable_elem_location behaviours, although we can consider it a separate issue. [0] https://github.com/llvm/llvm-project/pull/130255 -- Thanks, Jeremy -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org<mailto:Dwarf-discuss@lists.dwarfstd.org> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
