(hopefully this doesn't get too lost in all the other discussion in this thread - maybe best to spin things out under separate subject lines/subthreads?)
(I'm looking into this more in the context of LLVM trying to solve the downcasting part of this, motivated by Sony's SCE debugger but also with interest from LLDB & some perspective on GDB provided by Tom Tromey and much appreciated: https://github.com/llvm/llvm-project/pull/130255 ) On Tue, May 6, 2025 at 6:20 PM Cary Coutant via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> 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 proposed mechanism is a single attribute on the type with the location description of the vtable (given a pointer to the object), yeah? I wouldn't think this would address one of the discussed/requested needs, which is to know where/how much space it takes up in the layout/that the gap is not padding, right? If you wanted to know the layout, you'd have to partially evaluate the expression to get to the pointer - whereas the expression when fully evaluated would give you the vtable itself, having passed through the vtable pointer already. Is there a use case where there isn't a vtable pointer in the layout that can be described like another member? (admittedly encoding a member takes more bytes of DWARF than a single location attribute) > > - 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. > > Introducing such a niche list to the CU feels a bit awkward - if vtables were encoded as artificial static member variables (with some more DWARF-supported attribute to distinguish them) then perhaps we could introduce DW_AT_data_ranges to the CU for data ranges more generally, and lookup vtables by address through that? It'd address the gap that aranges->CU ranges left and this specific vtable use case as well. > > - 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. > > This sounds OK to me - yeah, GCC and LLVM can move to the constant encoding and then maybe, one day, eventually, GDB and LLDB could drop support for the mis-implemented expression-evaluated-to-constant-offset. > -cary > > > On Fri, May 2, 2025 at 1:31 PM Todd Allen via Dwarf-discuss < > 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 >> 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 >
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
