Pulling out part of my reply from the previous thread to focus on the first of the three parts, 250506.1 <https://dwarfstd.org/issues/250506.1.html>
On Tue, May 13, 2025 at 8:05 AM David Blaikie <[email protected]> wrote: > (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 < > [email protected]> 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) > Reiterating here that this solution doesn't address the petitioners point (1) about structure layout/identifying the vtable pointer bytes in the object representation. Any way we could verify (presumably the original GCC bug reporter from 20 years ago isn't interested in this anymore - but maybe they are?) whether that use case is important? I'm sort of of the opinion that it isn't - DWARF consumers shouldn't care how the layout came to be, they should just consume it. but equally - if the vtable pointer is effectively an unnamed member (I'd say it is) - maybe it's simpler for consumers to model it as such? Separately, we discussed in the last meeting where this DW_AT_vtable_location should be used. I think the DWARF spec is sufficiently vague/non-prescriptive that we maybe don't need to say anything about this. We just say it can be used and its up to implementations to choose how to use it? But if we want some non-normative text, I'd say we suggest its use on any type that defines a vtable pointer artificial member. (might be easier/obvious/not need to be said if we modeled it as an artificial member instead, though)
-- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
